File fetchmail-CVE-2025-61962.patch of Package fetchmail.41233

commit 4c3cebfa4e659fb778ca2cae0ccb3f69201609a8
Author: Matthias Andree <matthias.andree@gmx.de>
Date:   Fri Oct 3 13:11:59 2025 +0200

    Security fix: avoid NULL+1 deref on invalid AUTH reply
    
    When fetchmail receives a 334 reply from the SMTP server
    that does not contain the mandated blank after that response
    code, it will attempt reading from memory location 1, which
    will usually lead to a crash.
    
    The simpler fix would have been to check for four bytes "334 "
    instead of three bytes "334" but that would make malformed
    replies and those that don't match the expected reply code
    indistinguishable.

Index: fetchmail-6.3.26/smtp.c
===================================================================
--- fetchmail-6.3.26.orig/smtp.c
+++ fetchmail-6.3.26/smtp.c
@@ -89,6 +89,11 @@ static void SMTP_auth(int sock, char smt
 		}
 
 		p = strchr(tmp, ' ');
+		if (!p) {
+			report(stderr, "%s: \"%s\"\n", GT_("Malformed server reply"), visbuf(tmp));
+			SMTP_auth_error(sock, "");
+			return;
+		}
 		p++;
 		/* (hmh) from64tobits will not NULL-terminate strings! */
 		if (from64tobits(b64buf, p, sizeof(b64buf) - 1) <= 0) {
@@ -139,6 +144,11 @@ static void SMTP_auth(int sock, char smt
 		}
 
 		p = strchr(tmp, ' ');
+		if (!p) {
+			report(stderr, "%s: \"%s\"\n", GT_("Malformed server reply"), visbuf(tmp));
+			SMTP_auth_error(sock, "");
+			return;
+		}
 		p++;
 		if (from64tobits(b64buf, p, sizeof(b64buf) - 1) <= 0) {
 			SMTP_auth_error(sock, GT_("Bad base64 reply from server.\n"));