CVE-2023-6246 is a High severity (CVSS 8.4) heap based buffer overflow in glibc's internal syslog function, which affects glibc 2.36 and newer. A local attacker could crash a program or gain privileges. Red Hat's tracker lists the fix in glibc 2.39, so update glibc and rebuild images.
What's affected
The NVD description and Red Hat's bug entry agree on the core facts.
- Affected: glibc 2.36 and newer. The record's product list includes Fedora 38 and Fedora 39.
- Fixed: Red Hat's Bugzilla entry lists "Fixed In Version: glibc 2.39".
- Severity: 8.4 High. Red Hat rates it as high priority and severity in its tracker.
The trigger is specific. The bug occurs when the program has not called openlog, or has called it with a null ident argument, and the program's own name (the basename of its first argument) is longer than 1024 bytes. The function in question is called by syslog and vsyslog.
Red Hat's position. Red Hat's customer portal statement says that glibc as shipped in Red Hat products is not affected, because the issue was introduced in glibc 2.36 and no Red Hat product uses that version. That is a statement about Red Hat's own packages. Fedora, and any image or distribution carrying glibc 2.36 or later, can be affected.
How to check if you're exposed
Find the glibc version on hosts and inside images.
ldd --version
getconf GNU_LIBC_VERSION
For container images, run the same command inside the image.
docker run --rm --entrypoint ldd IMAGE --version
Replace IMAGE with your image name. Many minimal base images ship glibc, while Alpine based images use musl and are outside this CVE. A result of 2.36 to 2.38 is in range unless your distribution has backported the fix. Check the distribution tracker for the package version, not just the upstream number.
A scan of images and manifests is faster than checking one image at a time. The free in-browser dependency scan covers dependency manifests, and image scanning covers the OS layer.
What to do now
- Update the glibc package through your distribution's security update, or move to a base image that includes the fixed build.
- Rebuild and redeploy container images that bundle glibc 2.36 or later, since updating the host does not change the image.
- List setuid programs and services on affected hosts that log through syslog, and prioritize those.
- Do not rely on program name length limits as a control. Patch the library.
- Record base image and glibc version in your inventory so the next libc advisory is a query, not a hunt.
Why it matters
The weaknesses are CWE-122, a heap based buffer overflow, and CWE-787, an out of bounds write. The function allocates a buffer based on the assumption that the program name is short. A longer name makes the later copy write past the end of the heap allocation.
For a local attacker the practical question is whether they control a program name and whether that program runs with more privilege than they have. Setuid binaries are the classic case, because the caller picks how the program is invoked. That is why the description mentions local privilege escalation and not only a crash. The record's kev flag is false and the sources I retrieved do not report exploitation. The references include public write ups on packet storm and the full disclosure list, which I did not use for details.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is Red Hat Enterprise Linux affected by CVE-2023-6246?
Red Hat's statement says no, because it ships no glibc as new as 2.36. Fedora and other distributions on 2.36 or later can be affected.
Is updating the host enough for containers?
No. Each image carries its own libc, so each affected image needs a rebuild.
Sources
Last reviewed: 19 October 2026.
