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.
The following security advisories have been published:
GLIBC-SA-2026-0003: =================== wordexp with WRDEREUSE and WRDEAPPEND may return uninitialized memory
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.
The implementation of WRDEREUSE in conjunction with WRDEAPPEND fails to clear the wewordc member of the structure, and as such, when new words are added internally, a leading wewordc count number of entries are skipped since they are assumed initialized. These skipped entries are not initialized, but are the contents of a realloc-expanded array of pointers. If the caller inspects the wewordv array, it will dereference invalid pointers and crash. If the caller calls wordfree, the malloc implementation may detect the invalid pointers and abort the process. Calls to wordexp using WRDEREUSE and WRDEAPPEND have never worked correctly and thus the existence of applications that make use of this feature is unlikely.
CVE-Id: CVE-2025-15281 Public-Date: 2026-01-20 Vulnerable-Commit: 8f2ece695d8822e9ecc63ecd157e90bf17a6fe65 (1.93-260) Fix-Commit: 80cc58ea2de214f85b0a1d902a3b668ad2ecb302 (2.43) Reported-by: Vitaly Simonovich
Notes: ======
Published advisories are available directly in the project git repository: https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD
-- Cheers, Carlos.
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 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.
The following security advisories have been published:
GLIBC-SA-2026-0002: =================== getnetbyaddr and getnetbyaddrr leak stack contents to DNS resovler
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.
A defect in the nssdnsgetnetbyaddrr function which implements getnetbyaddr and getnetbyaddrr in the dns-based network database can pass stack contents unmodified to the configured DNS resolver as part of the network DNS query when the network queried is the default network i.e. net == 0x0. This stack contents leaking in the query is considered a loss of confidentiality for the host making the query. Typically it is rare to call these APIs with a net value of zero, and if an attacker can control the net value it can only leak adjacent stack, and so loss of confidentiality is spatially limited. The leak might be used to accelerate an ASLR bypass by knowing pointer values, but also requires network adjacent access to snoop between the application and the DNS server; making the attack complexity higher.
CVE-Id: CVE-2026-0915 Public-Date: 2026-01-15 Vulnerable-Commit: 5f0e6fc702296840d2daa39f83f6cb1e40073d58 (1.92-1) Fix-Commit: e56ff82d5034ec66c6a78f517af6faa427f65b0b (2.43) Reported-by: Igor Morgenstern, Aisle Research
Notes: ======
Published advisories are available directly in the project git repository: https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD
-- Cheers, Carlos.
The following security advisories have been published:
GLIBC-SA-2026-0001: ===================
Integer overflow in memalign leads to heap corruption
Passing too large an alignment to the memalign suite of functions (memalign, posixmemalign, alignedalloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.
Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFFMAX so as to overflow sizet along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62 + 1, 1<<63] and exactly 1<<63 for posixmemalign and alignedalloc.
Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.
CVE-Id: CVE-2026-0861 Public-Date: 2026-01-14 Vulnerable-Commit: 9bf8e29ca136094f73f69f725f15c51facc97206 (2.30) Fix-Commit: c9188d333717d3ceb7e3020011651f424f749f93 (2.43) Fix-Commit: 7f19ef14fbce095d4c77395e258320cad2ea2b28 (2.30-153) Fix-Commit: f18446d7b4a423090ee5e328c36b3c2a0f26041c (2.31-166) Fix-Commit: 8aef9e7a7af9565c0324b4ecb38b30dfa3782fd8 (2.32-151) Fix-Commit: 011293b4fd748cdd6f95874ba2b6aba9a3df8bff (2.33-275) Fix-Commit: 2c77e52108a58956c9f674b36e1f59a4e3fdcf4d (2.34-525) Fix-Commit: 499d1ccafccfe64df1b88deea2fa84d8180e8e8f (2.35-399) Fix-Commit: fb6b8822175769b5794fb6ea04f2895483a29b61 (2.36-244) Fix-Commit: 7b913d41a07836def826f2164c52541a9835f324 (2.37-172) Fix-Commit: 744b63026a29f7eedbbc8e3a01a7f48a6eb0a085 (2.38-212) Fix-Commit: fb22fd3f5b415dd4cd6f7b5741c2f0412374e242 (2.39-286) Fix-Commit: bfc4dd9e526eacf3017dd8864ba0848e9d045dd4 (2.40-216) Fix-Commit: 1e2c1ea4307197ccece0cda574bcfebf9080894c (2.41-121) Fix-Commit: b0ec8fb689df862171f0f78994a3bdeb51313545 (2.42-49) Reported-by: Igor Morgenstern, Aisle Research
Notes: ======
Published advisories are available directly in the project git repository: https://sourceware.org/git/?p=glibc.git;a=tree;f=advisories;hb=HEAD
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.
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.
Passing too large an alignment to the memalign suite of functions (memalign, posixmemalign, alignedalloc, valloc, pvalloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.
Integer overflow in memalign leads to heap corruption
The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.
The strncmp implementation optimized for the Power10 processor in the GNU C Library version 2.40 and later writes to vector registers v20 to v31 without saving contents from the caller (those registers are defined as non-volatile registers by the powerpc64le ABI), resulting in overwriting of its contents and potentially altering control flow of the caller, or leaking the input strings to the function to other parts of the program.
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).
From: Solar Designer <solar () openwall com> Sent: Friday, May 16, 2025 10:59 PM To: Carlos O'Donell <carlos () redhat com> Cc: oss-security () lists openwall com Subject: Re: [oss-security] The GNU C Library security advisories update for 2025-05-16
[...]
Notably, Go produces static binaries, and I guess would include glibc from its own build? Do they also use any of the affected functions? Searching around shows people building Go programs complain about the glibc "warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" (and ditto for some other functions), but only a subset (maybe none?) of those programs would be installed SUID/SGID/setcaps. Are we aware of any?
Alexander Go has poor support for SUID/SGID out of the box, due to interactions between the semantics of goroutines and Linux setugid syscalls applying on a per-thread basis. AIUI it's explicitly advised to not drop/gain privileges within a Golang binary itself. I would imagine capabilities have similar drawbacks since they are also per-thread attributes.
OTOH, much of the Golang software I've seen that does need privileges tends to be run as root directly, making this attack a bit of a moot point.
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).
Hi all,
On Wed, Jan 22, 2025 at 01:41:36PM +0000, Qualys Security Advisory wrote: Today (January 22, 2025) a Bugzilla entry and a patch proposal for this vulnerability have been published: The final patch has already been committed and backported, all the links are available in Bugzilla:
https://sourceware.org/bugzilla/showbug.cgi?id=32582
Thank you very much to the GNU C Library's security team for the quick fix and their work on this!
With best regards,
-- the Qualys Security Advisory team
When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.
Last updated 10 February 2025
On Tue, Dec 24, 2024 at 12:36 AM Florian Weimer <fweimer () redhat com> wrote: On Mon, Dec 23, 2024 at 8:47 PM Florian Weimer <fweimer () redhat com> wrote: It's a bit odd that you disable reflexivity checks by default, but quite a few of the issues reported are in this category. I think back then I wanted to make default settings free of false positives. Often sorted arrays may only contain unique elements and in such cases reflexivity checks are useless. Are they? In the longstanding glibc quicksort implementation (usually hidden behind a merge sort), reflexivity was required to rediscover an element that the implementation assumed to be there and dependent upon for loop termination. Interesting. I remember being told in GCC mailing list (or was it IRC?) that qsort implementations typically will not compare element to itself.
See also https://gcc.gnu.org/pipermail/gcc/2018-January/225098.html
-Y
Yuri Gribov: On Mon, Dec 23, 2024 at 8:47 PM Florian Weimer <fweimer () redhat com> wrote: It's a bit odd that you disable reflexivity checks by default, but quite a few of the issues reported are in this category. I think back then I wanted to make default settings free of false positives. Often sorted arrays may only contain unique elements and in such cases reflexivity checks are useless. Are they? In the longstanding glibc quicksort implementation (usually hidden behind a merge sort), reflexivity was required to rediscover an element that the implementation assumed to be there and dependent upon for loop termination. Other quicksort implementations seem to have similar requirements. For monomorphizing implementations such as std::sort for C++ not doing the pointer (iterator) check actually makes sense from a performance perspective.
Thanks, Florian
On Mon, Dec 23, 2024 at 8:47 PM Florian Weimer <fweimer () redhat com> wrote: It's a bit odd that you disable reflexivity checks by default, but quite a few of the issues reported are in this category. I think back then I wanted to make default settings free of false positives. Often sorted arrays may only contain unique elements and in such cases reflexivity checks are useless.
-Y
Yuri Gribov: Even with very basic setup (semi-automatic testing of Debian packages, no fuzzing) the tool was able to find numerous bugs in open-source programs (see e.g. https://github.com/yugr/sortcheck?tab=readme-ov-file#what-are-current-results). I believe many (10x) more bugs are still out there, waiting for more patient testers. It's a bit odd that you disable reflexivity checks by default, but quite a few of the issues reported are in this category.
The prevalence of these defects matches what we saw with glibc when we introduced an implementation that absolutely required that the comparison function returns zero if passed equal elements. We had to add explicit pointer equality checks in a couple of places to make it work. (Of course, this was before we reverted back to merge sort.)
Thanks, Florian
On Saturday 2024-12-21 15:29, Yuri Gribov wrote: I've recently come across discussion of invalid qsort comparators (and unpleasant consequences which they may have) at https://www.openwall.com/lists/oss-security/2024/01/30/7 and https://www.openwall.com/lists/oss-security/2024/06/24/3 For the record, I'll add https://gcc.gnu.org/bugzilla/showbug.cgi?id=113159 (2023/12/27)
Hi colleagues,
I've recently come across discussion of invalid qsort comparators (and unpleasant consequences which they may have) at https://www.openwall.com/lists/oss-security/2024/01/30/7 and https://www.openwall.com/lists/oss-security/2024/06/24/3
I myself have run into similar issues in the past and ended up developing a dynamic checker to detect them automatically: https://github.com/yugr/sortcheck (and its C++ analog at https://github.com/yugr/sortcheckxx for std::sort and other relevant STL APIs).
Even with very basic setup (semi-automatic testing of Debian packages, no fuzzing) the tool was able to find numerous bugs in open-source programs (see e.g. https://github.com/yugr/sortcheck?tab=readme-ov-file#what-are-current-results). I believe many (10x) more bugs are still out there, waiting for more patient testers.
Please let me know if someone is interested in applying these tools to their programs/distros.
Best regards, Yury "yugr" Gribov
PS: In case anyone wants more background on comparators, here is a presentation with some general theory, most popular errors and overview of existing tooling: https://github.com/yugr/CppRussia/blob/master/2023/EN.pdf
<https://www.avast.com/sig-email?utmmedium=email&utmsource=link&utmcampaign=sig-email&utmcontent=webmail> Никаких вирусов.www.avast.com <https://www.avast.com/sig-email?utmmedium=email&utmsource=link&utmcampaign=sig-email&utmcontent=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Jul 26, 2024 at 01:05:09PM -0700, Alan Coopersmith wrote: Yes, this came up in the discussion to add asprintf() to POSIX in https://austingroupbugs.net/view.php?id=1496 : Of the above listed implementations, all but GNU libc document that they will set ptr to NULL on error, while GNU libc explicitly states that you cannot rely on it to do so (and looking at its code, sometimes it does, sometimes it doesn't). and so the standard was written to allow both ways to be conformant.
If GNU libc was willing to change that, perhaps the next version of the standard could as well. I didn't know you contributed to getting this standardized. Thank you!
I think glibc should change, but the standard should merely strongly encourage libc's to implement the safer behavior. It shouldn't guarantee it because older glibc systems will remain in use.
Alexander
Hi Solar, all,
On Sun, Feb 04, 2024 at 05:35:20PM +0100, Solar Designer wrote: It's so invasive I cannot easily tell whether qsort() remained robust after it or not. There's no longer a "tmpptr != baseptr &&" check. So, lacking known-working tests in glibc tree, we don't know about glibc 2.39's status with respect to this issue. The "tmpptr != baseptr" bounds check was originally added to the quicksort() function, but is not needed anymore in glibc 2.39 because the old fallback to quick sort (the quicksort() function) has been completely removed and replaced by a fallback to heap sort.
Note, just in case: we have not reviewed the implementation of this new fallback to heap sort. Great findings and excellent quality write-up from Qualys, as usual. Thank you very much for your kind words!
With best regards,
-- the Qualys Security Advisory team