CVE-2023-6779 is a high severity (CVSS 8.2) off-by-one heap buffer overflow in the __vsyslog_internal function of glibc, which affects glibc 2.37 and newer. It is reached when syslog or vsyslog receives a message larger than INT_MAX bytes. Apply your distribution's glibc update.
What's affected
The description says the issue affects glibc 2.37 and newer. The record's product list includes the GNU C Library and Fedora 38 and 39. Distribution vendors publish their own fixed package versions, and the Red Hat page and the full disclosure post referenced by the record were not readable for this post, so check your vendor's advisory for the exact fixed package.
To trigger it, an application must pass a message over INT_MAX bytes (about 2 GiB) to syslog or vsyslog. Most programs never do, which is why the described result is a crash and the practical risk depends on your applications.
How to check if you're exposed
Find the glibc version and package build on each host and image.
ldd --version | head -n 1
rpm -q glibc # RPM-based systems
dpkg -l libc6 # Debian and Ubuntu
Compare the package version with your vendor's advisory for CVE-2023-6779. In container images, run the same commands inside the image, since base images carry their own glibc.
What to do now
- Install the glibc package update from your Linux vendor and restart services that use it. Long-running daemons keep the old library loaded until they restart.
- Rebuild and redeploy container images from a patched base image.
- Identify applications that log attacker-influenced data of large size through syslog, and cap message length.
- Scan images and hosts for the package so stragglers show up.
- Run your dependency manifests and images through the free in-browser scan at gold.safeguard.sh/scan, and use reachability analysis to see whether the affected code is actually used in your build.
Why it matters
The bug is a miscalculation of the buffer size when the message is huge. The size arithmetic goes wrong, the buffer ends up one byte too small, and a heap write goes past it. The record tags CWE-122 and CWE-787. NVD's description says the outcome is an application crash.
Memory safety bugs like this one come from code that trusts a length it never verified. In C and C++ the compiler will not stop a write past the end of a buffer, so the check has to be written by hand and has to be right on every path. Because glibc sits under nearly every Linux program, even rare paths in it get wide exposure. That is the reason to patch the base layer on a schedule rather than waiting for a proven attack.
Base libraries reach your estate by many routes: operating system packages, container base images and statically linked builds. Update the source of each route, not only the host you checked first. Rebuild images, restart long-running processes, and verify afterward with a fresh scan.
Weakness class in the record: CWE-122 (Heap-based Buffer Overflow) CWE-787 (Out-of-bounds Write).
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to patch if my apps never log 2 GiB messages?
The risk is low for those apps, but base library updates are routine and cheap. Apply the vendor update during normal maintenance.
How do I know all my images and hosts are covered?
Scan every image and host for the affected package and version. Images built before the fix keep the old library until they are rebuilt, and running processes keep it until they restart.
Sources
Last reviewed: 19 October 2026.
