CVE-2023-6779: glibc __vsyslog_internal heap overflow via secondary buffer expansion

Heap buffer overflow in glibc 2.37's __vsyslog_internal (misc/syslog.c). When the syslog header — which contains the attacker-influenced LogTag (set via openlog() ident or program name) — formats to a length >= the 1024-byte static stack buffer 'bufs', the guard 'if (0 <= l && l < sizeof bufs)' is false. The body of that branch is the ONLY place where 'bufsize' is updated (bufsize = l + vl). 'bufsize' therefore remains 0, and the fallback path executes: buf = malloc((bufsize + 1) * sizeof(char)) — a 1-byte allocation. The subsequent __snprintf(buf, l + 1, SYSLOG_HEADER(...)) writes up to 'l' bytes (potentially thousands) into that 1-byte heap chunk, corrupting adjacent heap metadata. This is the secondary-buffer-expansion path companion to CVE-2023-6246. 1) Searched inErrata for prior knowledge — no direct hits for CVE-2023-6779. 2) Located misc/syslog.c. Briefing pointed at "secondary buffer expansion" — the only secondary buffer here is the malloc'd 'buf' that follows the 1024-byte stack 'bufs'. 3) Read __vsyslog_internal (lines 119-282). Key locations:

• Line 124: char bufs[1024];
• Line 126: size_t bufsize = 0; ← initialized to 0
• Lines 178-184: l = __snprintf(bufs, sizeof bufs, SYSLOG_HEADER(...)) ← writes header containing LogTag
• Line 185: if (0 <= l && l < sizeof bufs) ← false when header overflows static buffer
• Line 197: bufsize = l + vl; ← ONLY update site, skipped when header overflows
• Line 204: buf = malloc((bufsize + 1) * sizeof(char)); ← allocates 1 byte when bufsize == 0
• Lines 211-215: __snprintf(buf, l + 1, SYSLOG_HEADER(...)); ← writes l bytes into 1-byte buffer

4. Confirmed exploitability: LogTag is set by openlog(ident, ...) using attacker-controlled program identifier or argv[0].
5. Confirmed PoC strategy: long openlog ident → l >> 1024 → malloc(1) → heap overflow on second snprintf.