Last updated 30 June 2026
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 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.
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.
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 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
A flaw has been identified in glibc. In an uncommon situation, the gaihinet function may use memory that has been freed, resulting in an application crash. This issue is only exploitable when the getaddrinfo function is called and the hosts database in /etc/nsswitch.conf is configured with SUCCESS=continue or SUCCESS=merge.
Last updated 18 August 2025
DISPUTED GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may guess the heap addresses of pthreadcreated thread. The component is: glibc. NOTE: the vendor's position is "ASLR bypass itself is not a vulnerability."
DISPUTED GNU Libc current is affected by: Mitigation bypass. The impact is: Attacker may bypass ASLR using cache of thread stack and heap. The component is: glibc. NOTE: Upstream comments indicate "this is being treated as a non-security bug and no real threat."
The nscd daemon in the GNU C Library (glibc) before version 2.5 does not close incoming client sockets if they cannot be handled by the daemon, allowing local users to carry out a denial of service attack on the daemon.
The glob function in glob.c in the GNU C Library (aka glibc or libc6) before 2.27, when invoked with GLOBTILDE, could skip freeing allocated memory when processing the ~ operator with a long user name, potentially leading to a denial of service (memory leak).
Last updated 24 July 2024
Last updated 24 July 2024
GNU C Library (glibc) is vulnerable to a denial of service, caused by an error in the iconv program. By processing invalid multi-byte input sequences, a remote attacker could exploit this vulnerability to cause the application to enter into an infinite loop.
Last updated 25 August 2025
Buffer overflow in the gethostbynamer and other unspecified NSS functions in the GNU C Library (aka glibc or libc6) before 2.22 allows context-dependent attackers to cause a denial of service (crash) or execute arbitrary code via a crafted DNS response, which triggers a call with a misaligned buffer.
It was reported [1] that under high load, getaddrinfo() starts sending DNS queries to random file descriptors, e.g. some unrelated socket connected to a remote service.
[1]: https://sourceware.org/bugzilla/showbug.cgi?id=15946
An Invalid-free() flaw was found in the getaddrinfo() syscall of glibc. The bug only materializes if the getaddrinfo functions is called with the AIIDN flag, and if glibc has been compiled with libidn support.
This flaw was fixed in glibc-2.15 via the following commit:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=2e96f1c7
An Invalid-free() flaw was found in the getaddrinfo() syscall of glibc. The bug only materializes if the getaddrinfo functions is called with the AIIDN flag, and if glibc has been compiled with libidn support.
This flaw was fixed in glibc-2.15 via the following commit:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=2e96f1c7
Cyrus SASL 2.1.23, 2.1.26, and earlier does not properly handle when a NULL value is returned upon an error by the crypt function as implemented in glibc 2.17 and later, which allows remote attackers to cause a denial of service (thread crash and consumption) via (1) an invalid salt or, when FIPS-140 is enabled, a (2) DES or (3) MD5 encrypted password, which triggers a NULL pointer dereference.
A security flaw was found in the way strcoll() interface of glibc, the GNU libc libraries, performed failsafe back to alloca() routine when malloc() function call failed previously (due to out of memory [OOM] condition for example). If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.
Upstream bug report (including the reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14552#c0
Issue / part: 1) alloca() stack overflow from [1].
References: [2] http://www.openwall.com/lists/oss-security/2012/09/07/9 [3] http://www.openwall.com/lists/oss-security/2012/09/07/15 [4] http://www.openwall.com/lists/oss-security/2012/09/10/1 [5] http://www.openwall.com/lists/oss-security/2012/09/10/3 [6] http://www.openwall.com/lists/oss-security/2012/09/13/16
A security flaw was found in the way strcoll() interface of glibc, the GNU libc libraries, performed failsafe back to alloca() routine when malloc() function call failed previously (due to out of memory [OOM] condition for example). If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.
Upstream bug report (including the reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14552#c0
Issue / part: 1) alloca() stack overflow from [1].
References: [2] http://www.openwall.com/lists/oss-security/2012/09/07/9 [3] http://www.openwall.com/lists/oss-security/2012/09/07/15 [4] http://www.openwall.com/lists/oss-security/2012/09/10/1 [5] http://www.openwall.com/lists/oss-security/2012/09/10/3 [6] http://www.openwall.com/lists/oss-security/2012/09/13/16
An integer overflow, leading to buffer overflow flaw was found in the way the implementation of strcoll() routine, used to compare two strings based on the current locale, of glibc, the GNU libc libraries, performed calculation of memory requirements / allocation, needed for storage of the strings. If an application linked against glibc was missing an application-level sanity checks for validity of strcoll() arguments and accepted untrusted input, an attacker could use this flaw to cause the particular application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.
Upstream bug report (including reproducer): [1] http://sourceware.org/bugzilla/showbug.cgi?id=14547
Multiple integer overflows in the (1) strtod, (2) strtof, (3) strtold, (4) strtodl, and other unspecified "related functions" in stdlib in GNU C Library (aka glibc or libc6) 2.16 allow local users to cause a denial of service (application crash) and possibly execute arbitrary code via a long string, which triggers a stack-based buffer overflow.
It was discovered that the formatted printing functionality in glibc used extendalloca() incorrectly. A remote attacker could provide a specially crafted sequence of format specifiers, leading to a desynchronization within the buffer size handling, resulting in the use of uninitialized memory or, potentially, FORTIFYSOURCE format string protection mechanism bypass, when processed.
References: http://sourceware.org/bugzilla/showbug.cgi?id=13446 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a4647e727a2a52e1259474c13f4b13288938bed4