GNU glibc CVE-2023-6246
HIGHCVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
DescriptionNVD
A heap-based buffer overflow was found in the __vsyslog_internal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.
AnalysisAI
Local privilege escalation in GNU glibc 2.36 and newer arises from a heap-based buffer overflow in __vsyslog_internal, reachable via the syslog/vsyslog interfaces when openlog was not called (or called with a NULL ident) and argv[0]'s basename exceeds 1024 bytes. Any setuid/setgid binary on affected Linux distributions (including Fedora 38 and 39) that invokes syslog can be leveraged by a local attacker to crash the process or escalate privileges to root. Publicly available exploit code exists and EPSS sits at the 96th percentile, signaling meaningful real-world risk despite the local attack vector.
Technical ContextAI
glibc is the GNU C Library, the standard C library underpinning virtually every userland process on mainstream Linux distributions. The flaw resides in __vsyslog_internal, the shared backend for the syslog(3) and vsyslog(3) APIs defined in syslog.h. When a process never calls openlog (or passes ident=NULL), the implementation derives the log identifier from the basename of argv[0]; the affected code path miscomputes the heap buffer size needed to hold this identifier, allowing an attacker-controlled program name longer than 1024 bytes to overflow an allocation on the heap. This is a classic CWE-122 heap-based buffer overflow, and because argv[0] is attacker-controlled across an execve boundary, any setuid/setgid binary that ultimately calls syslog without first calling openlog with a non-NULL ident is exploitable. CPE data confirms upstream gnu:glibc and Fedora 38/39 as in-scope, and the issue was introduced in glibc 2.36, so distributions shipping that or newer (e.g., Fedora 36+, Debian trixie, recent Ubuntu) inherit the vulnerable code path.
RemediationAI
Upgrade glibc to a distribution-provided patched build as the primary fix: track and apply the vendor errata for your platform (e.g., Fedora updates for F38/F39 referenced from the Red Hat advisory and Bodhi, and equivalent DSA/USN/RHSA advisories from Debian, Ubuntu, and Red Hat). Where immediate patching is not feasible, the most effective compensating control is to reduce the setuid/setgid attack surface - audit setuid binaries with find / -perm -4000 and remove the setuid bit from non-essential binaries (trade-off: some admin tooling may break for non-root users), and consider mounting /tmp, /home, and user-writable filesystems with nosuid to prevent attacker-controlled setuid binaries from being staged. Mandatory access control via SELinux in enforcing mode or AppArmor profiles can further constrain post-exploitation, though it does not block the overflow itself. Disabling syslog usage in vulnerable programs is not a practical workaround since the affected function is invoked internally by libc consumers; do not rely on argv[0] length filtering at the shell layer because the attack uses execve directly.
Share
External POC / Exploit Code
Leaving vuln.today