Fetchmail has long had support to assemble log/error messages that are generated piecemeal, and takes care to reallocate the output buffer as needed. In the reallocation case, i. e. when long log messages are assembled that can stem from very long headers, and on systems that have a varargs.h/stdarg.h interface (all modern systems), fetchmail's code would fail to reinitialize the va_list argument to vsnprintf. The exact effects depend on the verbose mode (how many -v are given) of fetchmail, computer architecture, compiler, operating system and configuration. On some systems, the code just works without ill effects, some systems log a garbage message (potentially disclosing sensitive information), some systems log literally "(null)", some systems trigger SIGSEGV (signal #11), which crashes fetchmail, causing a denial of service on fetchmail's end. References: https://www.fetchmail.info/fetchmail-SA-2021-01.txt https://www.openwall.com/lists/oss-security/2021/07/28/5
Created fetchmail tracking bugs for this issue: Affects: fedora-all [bug 1987768]
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:1964 https://access.redhat.com/errata/RHSA-2022:1964
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-36386