Fix SIGSEGV when resizing report*() buffer.

Reported (with a different patch suggestion) by
Christian Herdtweck <christian.herdtweck@intra2net.com>.

Note that vsnprintf() calls va_arg(), and depending on operating system,
compiler, configuration, this will invalidate the va_list argument
pointer, so that va_start has to be called again before a subsequent
vsnprintf(). However, it is better to do away with the loop and the
trial-and-error, and leverage the return value of vsnprintf instead for
a direct one-off resizing, whilst taking into account that on SUSv2
systems, the return value can be useless if the size argument to
vsnprintf is 0.

1 files changed, 18 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 04239b16..67dc1f9e 100644
--- a/NEWS
+++ b/NEWS
@@ -82,6 +82,24 @@ removed from a 6.5.0 or newer release.)
   server to test against. Use GSSAPI.
 
 --------------------------------------------------------------------------------
+fetchmail-6.4.20 (not yet released):
+
+# SECURITY FIX:
+* When a log message exceeds c. 2 kByte in size, for instance, with very long 
+  header contents, and depending on verbosity option, fetchmail can crash or
+  misreport each first log message that requires a buffer reallocation.
+  fetchmail then reallocates memory and re-runs vsnprintf() without another 
+  call to va_start(), so it reads garbage. The exact impact depends on 
+  many factors around the compiler and operating system configurations used and 
+  the implementation details of the stdarg.h interfaces of the two functions
+  mentioned before. To fix CVE-2021-38386.
+
+  Reported by Christian Herdtweck of Intra2net AG, Tübingen, Germany.
+
+  He also offered a patch, which I could not take for fetchmail 6.4 because
+  it required a C99 system and I'd promised earlier that 6.4 would remain
+  compatible with C89 systems.
+--------------------------------------------------------------------------------
 fetchmail-6.4.19 (released 2021-04-24, 30026 LoC):
 
 # CHANGE: