An integer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a very long message, leading to an incorrect calculation of the buffer size to store the message, resulting in undefined behavior. This issue affects glibc 2.37 and newer.

Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow.

The getgrouplist function in the GNU C library (glibc) before version 2.3.5, when invoked with a zero argument, writes to the passed pointer even if the specified array size is zero, leading to a buffer overflow and potentially allowing attackers to corrupt memory.

manual/search.texi in the GNU C Library (aka glibc) before 2.2 lacks a statement about the unspecified tdelete return value upon deletion of a tree's root, which might allow attackers to access a dangling pointer in an application whose developer was unaware of a documentation update from 1999.

A stack overflow vulnerability was found in nan functions that could cause applications which process long strings with the nan function to crash or, potentially, execute arbitrary code.

Upstream bug:

https://sourceware.org/bugzilla/showbug.cgi?id=16962

CVE assignment:

http://seclists.org/oss-sec/2016/q1/153

DISPUTED GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may bypass stack guard protection. The component is: nptl. The attack vector is: Exploit stack buffer overflow vulnerability and use this bypass vulnerability to bypass stack guard. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat."

GNU glibc is vulnerable to a heap-based buffer overflow, caused by a buffer over-read flaw in the proceednextnode function in posix/regexec.c. By sending a specially-crafted argument using a case-insensitive regular-expression match, a remote attacker could overflow a buffer and execute arbitrary code on the system.

A flaw was found in glibc. An integer overflow in the implementation of the posixmemalign in memalign functions in the GNU C Library (aka glibc or libc6) 2.26 and earlier could cause these functions to return a pointer to a heap area that is too small, potentially leading to heap corruption.

References: https://sourceware.org/bugzilla/showbug.cgi?id=22343

Patch: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8e448310d74b283c5cd02b9ed7fb997b47bf9b22

Last updated 25 August 2025

An SSE2-optimized memmove implementation for i386 in sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S in the GNU C Library (aka glibc or libc6) 2.21 through 2.27 does not correctly perform the overlapping memory check if the source memory range spans the middle of the address space, resulting in corrupt data being produced by the copy operation. This may disclose information to context-dependent attackers, or result in a denial of service, or, possibly, code execution.

Last updated 25 August 2025

A buffer overflow vulnerability caused by an off-by-one error was found in glibc. It is possible that an attacker might use this to escalate his privileges or execute code.

Upstream patch:

http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2d1bd71ec70a31b01d01b734faa66bb1ed28961f

Upstream issue:

https://sourceware.org/bugzilla/showbug.cgi?id=22320

The malloc implementation in the GNU C Library (aka glibc or libc6), from version 2.24 to 2.26 on powerpc, and only in version 2.26 on i386, did not properly handle malloc calls with arguments close to SIZEMAX and could return a pointer to a heap region that is smaller than requested, eventually leading to heap corruption.

elf/dl-load.c in the GNU C Library (aka glibc or libc6) 2.19 through 2.26 mishandles RPATH and RUNPATH containing $ORIGIN for a privileged (setuid or ATSECURE) program, which allows local users to gain privileges via a Trojan horse library in the current working directory, related to the fillinrpath and decomposerpath functions. This is associated with misinterpretion of an empty RPATH/RUNPATH token as the "./" directory. NOTE: this configuration of RPATH/RUNPATH for a privileged program is apparently very uncommon; most likely, no such program is shipped with any common Linux distribution.

Last updated 24 July 2024

DISPUTED GNU Libc current is affected by: Re-mapping current loaded library with malicious ELF file. The impact is: In worst case attacker may evaluate privileges. The component is: libld. The attack vector is: Attacker sends 2 ELF files to victim and asks to run ldd on it. ldd execute code. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat."

glibc is vulnerable to a denial of service, caused by a memory corruption by the Name Service Cache Daemon's (nscd) netgroup cache when the NSS callback fails to store all strings in the provided buffer. A local attacker could exploit this vulnerability to corrupt memory and cause a denial of service.

A heap-based buffer overflow was found in the vsysloginternal 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.

Untrusted LDLIBRARYPATH environment variable vulnerability in the GNU C Library version 2.27 to 2.38 allows attacker controlled loading of dynamically shared library in statically compiled setuid binaries that call dlopen (including internal dlopen calls after setlocale or calls to NSS functions such as getaddrinfo).

Integer overflow in memalign leads to heap corruption

An off-by-one heap-based buffer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a message bigger than INTMAX bytes, leading to an incorrect calculation of the buffer size to store the message, resulting in an application crash. This issue affects glibc 2.37 and newer.

A stack-based buffer overflow in nscd was reported and assigned CVE-2024-33599.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=31677

---

nscd/netgroupcache.c (addinnetgrX):

497 struct indataset 498 { 499 struct datahead head; 500 innetgroupresponseheader resp; 501 } dataset 502 = (struct indataset ) mempoolalloc (db, 503 sizeof (dataset) + req->keylen, 504 1);

mempoolalloc fails and returns NULL.

This is possible if posixfallocate fails and the retry fails.

505 struct indataset datasetmem; 506 bool cacheable = true; 507 if (glibcunlikely (dataset == NULL)) 508 { 509 cacheable = false; 510 dataset = &datasetmem;

This structure has no room for req->keylen material.

511 } 512 513 dataheadinitpos (&dataset->head, sizeof (dataset) + req->keylen, 514 sizeof (innetgroupresponseheader), 515 he == NULL ? 0 : dh->nreloads + 1, result->head.ttl); 516 / Set the notfound status and timeout based on the result from 517 getnetgrent. / 518 dataset->head.notfound = result->head.notfound; 519 dataset->head.timeout = timeout; 520 521 dataset->resp.version = NSCDVERSION; 522 dataset->resp.found = result->resp.found; 523 / Until we find a matching entry the result is 0. / 524 dataset->resp.result = 0; 525 526 char keycopy = memcpy ((char ) (dataset + 1), group, req->keylen);

This copies up to req->keylen material to a structure that has no storage space for it.

This was detected by static code analysis.

It will only happen in the case the database runs out of memory/storage while expanding the netgroup cache.

The group entries overwrite other data on the stack after datasetmem.

The workaround is not to cache the netgroup if this is impacting the use of the application.

An exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.

Last updated 25 August 2025

A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.

An AVX-512-optimized implementation of the mempcpy function in the GNU C Library (aka glibc or libc6) 2.27 and earlier may write data beyond the target buffer, leading to a buffer overflow in mempcpyavx512novzeroupper.

A memory leak in glibc 2.1.1 (released on May 24, 1999) can be reached and amplified through the LDHWCAPMASK environment variable. Please note that many versions of glibc are not vulnerable to this issue if patched for CVE-2017-1000366.

A buffer underflow in realpath() in glibc when getcwd() returns relative path or unreachable path (i.e. not starting with '/') was found that can allow privilege escalation under certain conditions.

Reference:

http://www.openwall.com/lists/oss-security/2018/01/11/5

A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.

glibc is vulnerable to a denial of service, caused by a memory allocation failure when the Name Service Cache Daemon's (nscd) netgroup cache uses the xmalloc or xrealloc functions. A local attacker could exploit this vulnerability to terminate the daemon.