https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 12:48:11 +0000 https://cve.radiocsirt.org/vuln/alsa-2026:1334 <p><strong>Affected:</strong> AlmaLinux:10: glibc-doc</p> <p>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.</p> <p>Security Fix(es):</p> <p>* glibc: Integer overflow in memalign leads to heap corruption (CVE-2026-0861) * glibc: glibc: Information disclosure via zero-valued network query (CVE-2026-0915)</p> <p>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.</p> <p><strong>Affected:</strong> AlmaLinux:10: glibc-doc</p> <p>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.</p> <p>Security Fix(es):</p> <p>* glibc: Integer overflow in memalign leads to heap corruption (CVE-2026-0861) * glibc: glibc: Information disclosure via zero-valued network query (CVE-2026-0915)</p> <p>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.</p> https://cve.radiocsirt.org/vuln/alsa-2026:1334 https://cve.radiocsirt.org/vuln/bdu:2026-00915 bdu:2026-00915 https://cve.radiocsirt.org/vuln/bdu:2026-00915 https://cve.radiocsirt.org/vuln/bell-cve-2026-0861 <p><strong>Affected:</strong> Alpaquita:23: glibc, Alpaquita:25: glibc, Alpaquita:stream: glibc, BellSoft Hardened Containers:23: glibc, BellSoft Hardened Containers:25: glibc, BellSoft Hardened Containers:stream: glibc</p> <p><strong>Affected:</strong> Alpaquita:23: glibc, Alpaquita:25: glibc, Alpaquita:stream: glibc, BellSoft Hardened Containers:23: glibc, BellSoft Hardened Containers:25: glibc, BellSoft Hardened Containers:stream: glibc</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-0861 https://cve.radiocsirt.org/vuln/brew-glibc-cve-2026-0861 <p><strong>Affected:</strong> Homebrew: glibc</p> <p>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.</p> <p>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.</p> <p>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.</p> <p><strong>Affected:</strong> Homebrew: glibc</p> <p>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.</p> <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/brew-glibc-cve-2026-0861 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0199 certfr-2026-avi-0199 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0199 https://cve.radiocsirt.org/vuln/euvd-2026-307834 EUVD-2026-307834 https://cve.radiocsirt.org/vuln/euvd-2026-307834 https://cve.radiocsirt.org/vuln/fkie_cve-2026-0861 <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-0861 https://cve.radiocsirt.org/vuln/ghsa-5pf6-63v3-88hw <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ghsa-5pf6-63v3-88hw https://cve.radiocsirt.org/vuln/msrc_cve-2026-0861 msrc_CVE-2026-0861 https://cve.radiocsirt.org/vuln/msrc_cve-2026-0861 https://cve.radiocsirt.org/vuln/oesa-2026-1198 <p><strong>Affected:</strong> openEuler:24.03-LTS: glibc</p> <p>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):</p> <p>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.</p> <p>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&amp;lt;&amp;lt;62+ 1, 1&amp;lt;&amp;lt;63] and exactly 1&amp;lt;&amp;lt;63 for posix_memalign and aligned_alloc.</p> <p>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…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: glibc</p> <p>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):</p> <p>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.</p> <p>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&amp;lt;&amp;lt;62+ 1, 1&amp;lt;&amp;lt;63] and exactly 1&amp;lt;&amp;lt;63 for posix_memalign and aligned_alloc.</p> <p>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…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1198 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10662-1 <p>glibc-2.43-1.1 on GA media</p> <p>glibc-2.43-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10662-1 https://cve.radiocsirt.org/vuln/rhsa-2026:3228 <p>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</p> <p>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</p> https://cve.radiocsirt.org/vuln/rhsa-2026:3228 https://cve.radiocsirt.org/vuln/suse-su-2026:0347-1 <p>Security update for glibc-livepatches</p> <p>Security update for glibc-livepatches</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0347-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-0861 <p><strong>Affected:</strong> Ubuntu:Pro:20.04:LTS: glibc, Ubuntu:22.04:LTS: glibc, Ubuntu:24.04:LTS: glibc, Ubuntu:25.10: glibc</p> <p>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 application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.</p> <p><strong>Affected:</strong> Ubuntu:Pro:20.04:LTS: glibc, Ubuntu:22.04:LTS: glibc, Ubuntu:24.04:LTS: glibc, Ubuntu:25.10: glibc</p> <p>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 application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-0861 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0118 <p>Ein lokaler Angreifer kann eine Schwachstelle in GNU libc ausnutzen, um beliebigen Programmcode auszuführen.</p> <p>Ein lokaler Angreifer kann eine Schwachstelle in GNU libc ausnutzen, um beliebigen Programmcode auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0118