Your message dated Sun, 4 Jan 2026 17:27:23 +0100
with message-id <[email protected]>
and subject line Re: Bug#1120380: trixie-pu: package fetchmail/6.4.39-1+deb13u1
has caused the Debian Bug report #1120380,
regarding trixie-pu: package fetchmail/6.4.39-1+deb13u1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1120380: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120380
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: [email protected], Laszlo Boszormenyi (GCS)
<[email protected]>, Matthias Andree <[email protected]>, [email protected]
Control: affects -1 + src:fetchmail
User: [email protected]
Usertags: pu
Dear Stable release managers, Laszlo, (CC upstream)
The time is bit tight now given window is closing this weekend for
uploads for the next trixie point release. I was looking which minor
CVE fixes are open, and noticed that we have CVE-2025-61962 which
might be low enough to still get in, but I would like to have an ack
from Lazslo, otherwise later point release is I guess fine.
[ Reason ]
fetchmail is pront to a SMTP client crash when authenticating against
a trusted but malicious or malfunctioning SMTP server. Details in
https://www.fetchmail.info/fetchmail-SA-2025-01.txt
This is CVE-2025-61962 and in Debian BTS tracked as #1117136.
[ Impact ]
fetchmail crash.
[ Tests ]
None in particular for this issue itself (as I have no setup available
makeing use of it). Lazslo?
I have uploaded the proposed package to debusine for further testing:
https://debusine.debian.net/debian/developers/work-request/229521/
[ Risks ]
Pick the upstream changes which are isolated for the changes in
smtp.c.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Check from malformed replied from the SMTP server, i.e. check in this
case the"334" responses not followed the mandated blank after the
repsonse code.
Regards,
Salvatore
diff -Nru fetchmail-6.4.39/debian/changelog fetchmail-6.4.39/debian/changelog
--- fetchmail-6.4.39/debian/changelog 2024-07-24 09:08:58.000000000 +0200
+++ fetchmail-6.4.39/debian/changelog 2025-11-08 14:51:41.000000000 +0100
@@ -1,3 +1,11 @@
+fetchmail (6.4.39-1+deb13u1) trixie; urgency=medium
+
+ * Non-maintainer upload.
+ * Security fix: avoid NULL+1 deref on invalid AUTH reply (CVE-2025-61962)
+ (Closes: #1117136)
+
+ -- Salvatore Bonaccorso <[email protected]> Sat, 08 Nov 2025 14:51:41 +0100
+
fetchmail (6.4.39-1) unstable; urgency=medium
* New upstream release.
diff -Nru
fetchmail-6.4.39/debian/patches/09_Security-fix-avoid-NULL-1-deref-on-invalid-AUTH-repl.patch
fetchmail-6.4.39/debian/patches/09_Security-fix-avoid-NULL-1-deref-on-invalid-AUTH-repl.patch
---
fetchmail-6.4.39/debian/patches/09_Security-fix-avoid-NULL-1-deref-on-invalid-AUTH-repl.patch
1970-01-01 01:00:00.000000000 +0100
+++
fetchmail-6.4.39/debian/patches/09_Security-fix-avoid-NULL-1-deref-on-invalid-AUTH-repl.patch
2025-11-08 14:50:14.000000000 +0100
@@ -0,0 +1,46 @@
+From: Matthias Andree <[email protected]>
+Date: Fri, 3 Oct 2025 13:11:59 +0200
+Subject: Security fix: avoid NULL+1 deref on invalid AUTH reply
+Origin:
https://gitlab.com/fetchmail/fetchmail/-/commit/4c3cebfa4e659fb778ca2cae0ccb3f69201609a8
+Bug-Debian: https://bugs.debian.org/1117136
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2025-61962
+
+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.
+---
+ smtp.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/smtp.c
++++ b/smtp.c
+@@ -92,6 +92,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) {
+@@ -145,6 +150,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"));
diff -Nru fetchmail-6.4.39/debian/patches/series
fetchmail-6.4.39/debian/patches/series
--- fetchmail-6.4.39/debian/patches/series 2023-01-10 03:29:55.000000000
+0100
+++ fetchmail-6.4.39/debian/patches/series 2025-11-08 14:48:49.000000000
+0100
@@ -2,3 +2,4 @@
04_invoke-rc.d.diff
07_properly_report_size_of_mailboxes.patch
08_remove_forced_OpenSSL_check.patch
+09_Security-fix-avoid-NULL-1-deref-on-invalid-AUTH-repl.patch
--- End Message ---
--- Begin Message ---
Hi László,
On Sat, Nov 08, 2025 at 09:32:01PM +0100, Salvatore Bonaccorso wrote:
> Hi László,
>
> On Sat, Nov 08, 2025 at 05:40:10PM +0100, László Böszörményi (GCS) wrote:
> > Hi Salvatore,
> >
> > On Sat, Nov 8, 2025 at 3:09 PM Salvatore Bonaccorso <[email protected]>
> > wrote:
> > > The time is bit tight now given window is closing this weekend for
> > > uploads for the next trixie point release. I was looking which minor
> > > CVE fixes are open, and noticed that we have CVE-2025-61962 which
> > > might be low enough to still get in, but I would like to have an ack
> > > from Lazslo, otherwise later point release is I guess fine.
> > s/Lazslo/Laszlo/.
>
> Sorry for the typo. I know you know I know your name, and apologies
> for the mistake hapened while typing, twice (I do often swap some
> letters, but proof reading would help).
>
> > While you are right, this should be fixed, please
> > note that the mentioned fix is not final. The 6.5.7 release contains a
> > bugfix [1] for this and noted as: "However, to improve compatibility,
> > fetchmail now accepts anything that starts with "334" and disregards
> > the remainder of the line.". See the full commit [2] for this.
>
> Thanks for pointing that out. That were exactly the things why I did
> want to hear feedback if the proposed update make sense.
>
> So for now I retract the proposed update.
>
>
> > > [ Tests ]
> > > None in particular for this issue itself (as I have no setup available
> > > makeing use of it). Lazslo?
> > s/Lazslo/Laszlo/; As you can read from the commit (in file NEWS
> > file), 'AUTH LOGIN' was a draft only, never made it to the IETF RFC.
> > As such, even if it is implemented in a mail server, 'AUTH PLAIN'
> > should precede such authentication. In short, I think such a
> > misbehaving IMAP server might not exist. This issue might be found by
> > a static code analyzer of fetchmail and not by actual usage.
> >
> > > I have uploaded the proposed package to debusine for further testing:
> > > https://debusine.debian.net/debian/developers/work-request/229521/
> > To be honest, I think a full package update should be done for Trixie
> > at least (probably a release after 6.6.0 as that has a minor glitch).
> > Reason is, even 6.5.x releases will lose support by the end of this
> > year (2025).
>
> Ok understood, we need to hear as well hear from SRM how they feel
> about such an update. I think what will be needed here is at least a
> (filtered) debdiff, along to illustrate the confidence on the rebase.
>
> > As I understand it, there was no support removed between 6.4.39
> > (Trixie) and the current (and long time supported release of) 6.6.0
> > version. We should get a solid base with the latter instead of
> > backporting specific commits. But let's hear what upstream developer
> > Matthias says on this.
>
> Ok, let's wait as well for input from Matthias.
There was AFAIK no followup and let's close this bug. In case there is
inerest to make an update it will be different anyway asthe proposed
one.
Regards,
Salvatore
--- End Message ---
