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.
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.
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).
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
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.
Last updated 10 February 2025
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 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 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.
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
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.
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.
The deprecated compatibility function svcunixcreate in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.
Reference: https://sourceware.org/bugzilla/showbug.cgi?id=28768
The deprecated compatibility function clntcreate in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.
Reference: https://sourceware.org/bugzilla/showbug.cgi?id=22542
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.
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
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
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: 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
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>
endpattern (called from internalfnmatch) in the GNU C Library (aka glibc or libc6) before 2.22 might allow context-dependent attackers to cause a denial of service (application crash), as demonstrated by use of the fnmatch library function with the (!() pattern. NOTE: this is not the same as CVE-2015-8984; also, some Linux distributions have fixed CVE-2015-8984 but have not fixed this additional fnmatch issue.
It was discovered that the glibc DNS resolver dereferenced a NULL pointer when processing a specific, but valid resource record type.
Acknowledgements:
Name: Florian Weimer (Red Hat Product Security)
Certain run-time memory protection mechanisms in the GNU C Library (aka glibc or libc6) print argv[0] and backtrace information, which might allow context-dependent attackers to obtain sensitive information from process memory by executing an incorrect program, as demonstrated by a setuid program that contains a stack-based buffer overflow error, related to the fortifyfail function in debug/fortifyfail.c, and the stackchkfail (aka stack protection) and chkfail (aka FORTIFYSOURCE) implementations.
DISPUTED ldd in the GNU C Library (aka glibc or libc6) 2.13 and earlier allows local users to gain privileges via a Trojan horse executable file linked with a modified loader that omits certain LDTRACELOADEDOBJECTS checks. NOTE: the GNU C Library vendor states "This is just nonsense. There are a gazillion other ways to introduce code if people are downloading arbitrary binaries and install them in appropriate directories or set LDLIBRARYPATH etc."