CVE-2023-6779: glibc syslog heap-overflow through secondary buffer expansion

Heap overflow vulnerability in glibc's syslog logging subsystem (version 2.37 and earlier). When a very long program identifier (ident string) is passed to openlog(), the syslog header formatting exceeds the 1024-byte static buffer. The code fails to properly track the required buffer size when the header exceeds the static buffer limit, leading to malloc(1) being called instead of the correct size. Subsequent snprintf() calls write the full header and message into this undersized heap buffer, causing a heap overflow that can lead to memory corruption and potential code execution.", Located vulnerability in misc/syslog.c, function __vsyslog_internal (lines 179-230). Analyzed the control flow: (1) Line 180-181: __snprintf formats header into bufs[1024], returns 'l' = intended length; (2) Line 185: if (0 <= l && l < 1024) checks if header fits; (3) Line 197: bufsize = l + vl is INSIDE the if-block, only executed if header < 1024 bytes; (4) If header > 1024 bytes, the condition fails and bufsize never gets set (remains 0); (5) Line 204: malloc((bufsize + 1)) with bufsize=0 allocates only 1 byte; (6) Lines 211-212: __snprintf writes full header to 1-byte buffer = overflow. Root cause is conditional buffer size tracking that fails when the primary buffer overflows. The PoC provided confirms this: openlog() with ~2000 char ident + syslog() call triggers the overflow.", The fix requires ensuring 'bufsize' is properly calculated before the malloc() call. When the header exceeds 1024 bytes, the code must: (1) detect that the static buffer was insufficient (l >= 1024), (2) calculate the actual header size needed, (3) determine the message size, (4) allocate heap buffer with total_header_size + total_message_size + 1. Alternatively, snprintf() can be called twice: once to determine the exact size needed, then with the correctly-sized heap buffer. The critical issue is that bufsize is only set inside the 'fast path' conditional, but used unconditionally in the 'slow path' (malloc). This must be fixed by either: (a) always computing bufsize before malloc, (b) using a safer calculation like __snprintf(..., 0) to probe the needed size, or (c) using a more conservative default size estimate when the fast path fails.", The vulnerability is confirmed by the provided PoC file (poc_cve_2023_6779.c) which successfully triggers the overflow by creating a 2000-character ident and calling syslog(). The heap overflow occurs because malloc(1) allocates insufficient space for the header and message formatting. The code path analysis confirms the bufsize=0 scenario is reachable and exploitable.", HeapOverflow", runtime", critical", logic_error", {"glibc": "2.37"}, ["heap-overflow", "glibc", "syslog", "CVE-2023-6779", "off-by-one", "buffer-management", "cold-baseline"], GNU C Library Logging Subsystem"