diff options
author | Matthias Andree <matthias.andree@gmx.de> | 2021-08-09 17:42:29 +0200 |
---|---|---|
committer | Matthias Andree <matthias.andree@gmx.de> | 2021-08-09 17:42:29 +0200 |
commit | d3db2da1d13bd2419370ad96defb92eecb17064c (patch) | |
tree | 3d6bd886cdf95fb45b56800d66175cbf3b37189f | |
parent | f6ebe48b0a0cc75838d4b4f78e1af7f7d5cc96b9 (diff) | |
download | fetchmail-d3db2da1d13bd2419370ad96defb92eecb17064c.tar.gz fetchmail-d3db2da1d13bd2419370ad96defb92eecb17064c.tar.bz2 fetchmail-d3db2da1d13bd2419370ad96defb92eecb17064c.zip |
Fix --logfile and message truncation issue.
Regression in 6.4.20's security fix (Git commit c546c829).
We doubly incremented partial_message_size_used on modern systems
(stdard.h/vsnprintf), once in report_vbuild() and then again in
report_build(), so the 2nd and subsequent report_build() fragments
landed too late in the buffer. This will not cause overruns due to the
reallocation prior to the vsnprintf/sprintf, but it write starts behind
the '\0' byte, instead of right over it, so the string also gets
truncated to the first fragment written with report_vbuild().
Fix by moving the increment back into the #else...#endif part that does
not use report_vbuild().
Reported by: Jürgen Edner, Erik Christiansen
-rw-r--r-- | NEWS | 18 | ||||
-rw-r--r-- | report.c | 3 |
2 files changed, 20 insertions, 1 deletions
@@ -82,6 +82,24 @@ removed from a 6.5.0 or newer release.) server to test against. Use GSSAPI. -------------------------------------------------------------------------------- +fetchmail-6.4.21 (released 2021-08-09, 30042 LoC): + +# REGRESSION FIX: +* The new security fix in 6.4.20 for CVE-2021-36386 caused truncation of + messages logged to buffered outputs, predominantly --logfile. + + This also caused lines in the logfile to run into one another because + the fragment containing the '\n' line-end character was usually lost. + + Reason is that on all modern systems (with <stdarg.h> header and vsnprintf() + interface), the length of log message fragments was added up twice, so + that these ended too deep into a freshly allocated buffer, after the '\0' + byte. Unbuffered outputs flushed the fragments right away, which masked the + bug. + + Reported by: Jürgen Edner, Erik Christiansen. + +-------------------------------------------------------------------------------- fetchmail-6.4.20 (released 2021-07-28, 30042 LoC): # SECURITY FIX: @@ -286,10 +286,11 @@ report_build (FILE *errfp, message, va_alist) n = snprintf (partial_message + partial_message_size_used, partial_message_size - partial_message_size_used, message, a1, a2, a3, a4, a5, a6, a7, a8); -#endif if (n > 0) partial_message_size_used += n; +#endif + if (unbuffered && partial_message_size_used != 0) { partial_message_size_used = 0; |