Affected: AlmaLinux:10: glibc-doc

The glibc packages provide the standard C libraries (libc), POSIX thread libraries (libpthread), standard math libraries (libm), and the name service cache daemon (nscd) used by multiple programs on the system. Without these libraries, the Linux system cannot function correctly.

Security Fix(es):

* glibc: Integer overflow in memalign leads to heap corruption (CVE-2026-0861) * glibc: glibc: Information disclosure via zero-valued network query (CVE-2026-0915)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Affected: Alpaquita:23: glibc, Alpaquita:25: glibc, Alpaquita:stream: glibc, BellSoft Hardened Containers:23: glibc, BellSoft Hardened Containers:25: glibc, BellSoft Hardened Containers:stream: glibc

Affected: Homebrew: glibc

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) 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 PTRDIFF_MAX so as to overflow size_t 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 posix_memalign and aligned_alloc.

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.

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) 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 PTRDIFF_MAX so as to overflow size_t 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 posix_memalign and aligned_alloc.

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.

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc, 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.

Affected: openEuler:24.03-LTS: glibc

The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. These libraries provide critical APIs including ISO C11, POSIX.1-2008, BSD, OS-specific APIs and more. These APIs include such foundational facilities as open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit and more. Security Fix(es):

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) 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 PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1&lt;&lt;62+ 1, 1&lt;&lt;63] and exactly 1&lt;&lt;63 for posix_memalign and aligned_alloc.

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 a…

glibc-2.43-1.1 on GA media

openssl: OpenSSL: Arbitrary code execution or denial of service through crafted PKCS#12 file glibc: wordexp with WRDE_REUSE and WRDE_APPEND may return uninitialized memory openssl: OpenSSL: Remote code execution or Denial of Service via oversized Initialization Vector in CMS parsing openssl: OpenSSL: Denial of Service via NULL pointer dereference in QUIC protocol handling openssl: OpenSSL: Data integrity bypass in `openssl dgst` command due to silent truncation openssl: OpenSSL: Denial of Service due to excessive memory allocation in TLS 1.3 certificate compression openssl: OpenSSL: Denial of Service due to out-of-bounds write in BIO filter openssl: OpenSSL: Information disclosure and data tampering via specific low-level OCB encryption/decryption calls openssl: OpenSSL: Arbitrary code execution due to out-of-bounds write in PKCS#12 processing openssl: OpenSSL: Denial of Service via malformed TimeStamp Response openssl: OpenSSL: Denial of Service via malformed PKCS#12 file processing glibc: Integer overflow in memalign leads to heap corruption glibc: glibc: Information disclosure via zero-valued network query openssl: OpenSSL: Denial of Service due to type confusion in PKCS#12 file processing openssl: OpenSSL: Denial of Service via type confusion in PKCS#7 signature verification

Security update for glibc-livepatches

Affected: Ubuntu:Pro:20.04:LTS: glibc, Ubuntu:22.04:LTS: glibc, Ubuntu:24.04:LTS: glibc, Ubuntu:25.10: glibc

Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) 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 PTRDIFF_MAX so as to overflow size_t 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 posix_memalign and aligned_alloc. 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.

Ein lokaler Angreifer kann eine Schwachstelle in GNU libc ausnutzen, um beliebigen Programmcode auszuführen.