Bug 1987766 (CVE-2021-36386) - CVE-2021-36386 fetchmail: DoS or information disclosure when logging long messages
Summary: CVE-2021-36386 fetchmail: DoS or information disclosure when logging long mes...
Status: NEW
Alias: CVE-2021-36386
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 2002698 2005307 1987768
Blocks: 1987770
TreeView+ depends on / blocked
Reported: 2021-07-29 16:15 UTC by Guilherme de Almeida Suckevicz
Modified: 2021-09-17 13:11 UTC (History)
2 users (show)

Fixed In Version: fetchmail 6.4.20
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in fetchmail. The flaw lies in how fetchmail when running in verbose mode using the -v flag tries to log long messages that are created from long headers. An attacker could potentially use this flaw to cause a Denial of Service attack or crash. The highest threat from this vulnerability is to data availability. This flaw was earlier identified by CVE-2008-2711 and fixed, however it recently got reintroduced due to a code refactoring issue. The current bug fix applies a different approach than the earlier one.
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2021-07-29 16:15:37 UTC
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.


Comment 1 Guilherme de Almeida Suckevicz 2021-07-29 16:15:52 UTC
Created fetchmail tracking bugs for this issue:

Affects: fedora-all [bug 1987768]

Note You need to log in before you can comment on or make changes to this bug.