Last updated 30 June 2026

Last updated 30 June 2026

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.

Calling the ungetwc function on a FILE stream with wide characters encoded in a character set that has overlaps between its single byte and multi-byte character encodings, in the GNU C Library version 2.43 or earlier, may result in an attempt to read bytes before an allocated buffer, potentially resulting in unintentional disclosure of neighboring data in the heap, or a program crash.

iconv crash due to assertion failure with untrusted input

Calling gethostbyaddr or gethostbyaddrr with a configured nsswitch.conf that specifies the library's DNS backend in the GNU C library version 2.34 to version 2.43 could result in an invalid DNS hostname being returned to the caller in violation of the DNS specification.

Calling gethostbyaddr or gethostbyaddrr with a configured nsswitch.conf that specifies the library's DNS backend in the GNU C Library version 2.34 to version 2.43 could, with a crafted response from the configured DNS server, result in a violation of the DNS specification that causes the application to treat a non-answer section of the DNS response as a valid answer.

Calling NSS-backed functions that support caching via nscd may call the nscd client side code and in the GNU C Library version 2.36 under high load on x8664 systems, the client may call memcmp on inputs that are concurrently modified by other processes or threads and crash.

The nscd client in the GNU C Library uses the memcmp function with inputs that may be concurrently modified by another thread, potentially resulting in spurious cache misses, which in itself is not a security issue.  However in the GNU C Library version 2.36 an optimized implementation of memcmp was introduced for x8664 which could crash when invoked with such undefined behaviour, turning this into a potential crash of the nscd client and the application that uses it. This implementation was backported to the 2.35 branch, making the nscd client in that branch vulnerable as well.  Subsequently, the fix for this issue was backported to all vulnerable branches in the GNU C Library repository.

It is advised that distributions that may have cherry-picked the memcpy SSE2 optimization in their copy of the GNU C Library, also apply the fix to avoid the potential crash in the nscd client.

Calling wordexp with WRDEREUSE in conjunction with WRDEAPPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the wewordv member, which on subsequent calls to wordfree may abort the process.

Calling getnetbyaddr or getnetbyaddrr with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.

Integer overflow in memalign leads to heap corruption

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).

An insufficient entropy vulnerability was found in glibc. The getrandom and arc4random family of functions may return predictable randomness if these functions are called again after the fork, which happens concurrently with a call to any of these functions.

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.

The buffer-resizing code in addgetnetgrentX assumes that all string pointers point into the supplied buffer.

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

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.

The netgroup cache uses xmalloc/xrealloc and may terminate the process due to a memory allocation failure.

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

After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header.

In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.

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

After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header.

In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.

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

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.

GNU C Library could allow a remote attacker to execute arbitrary code on the system, caused by an out-of-bounds write in the ISO-2022-CN-EXT plugin. By sending specially crafted input, an attacker could exploit this vulnerability to overwrite critical data structures and execute arbitrary code on the system or cause the application to crash.

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.

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 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.

A flaw was found in the GNU C Library. A recent fix for CVE-2023-4806 introduced the potential for a memory leak, which may result in an application crash.

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.

A flaw has been identified in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the nssgethostbyname2r and nssgetcanonnamer hooks without implementing the nssgethostbyname3r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AFINET6 address family with AICANONNAME, AIALL and AIV4MAPPED as flags.

In an extremely rare situation, the getaddrinfo function in glibc may access memory that has already been freed, resulting in an application crash.

This issue is only exploitable when a NSS module implements only the nssgethostbyname2r hook without implementing the nssgethostbyname3r hook. There are no known modules that are implemented in this way.

In addition to that condition, the resolved name should return a large number of IPv6 as well as IPv4 and the call to the getaddrinfo function should have AFINET6 with AICANONNAME, AIALL and AIV4MAPPED as flags.

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

A flaw was found in glibc. When the getaddrinfo function is called with the AFUNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash.

If the system is configured in no-aaaa mode via /etc/resolv.conf, getaddrinfo is called for the AFUNSPEC address family, and a DNS response is received over TCP that is larger than 2048 bytes, getaddrinfo may potentially disclose stack contents via the returned address data, or crash. While name lookup normally just fails incorrectly, crashes are not difficult to trigger, with valid DNS responses that are propagated by DNS resolvers.

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