<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 08:47:07 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-45990</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45990</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-45990</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0831 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</link>
      <description>certfr-2026-avi-0831</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0831</guid>
    </item>
    <item>
      <title>EUVD-2026-327067</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-327067</link>
      <description>EUVD-2026-327067</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-327067</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45990</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45990</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;slub: fix data loss and overflow in krealloc()&lt;/p&gt;
&lt;p&gt;Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in
k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the
original object does not satisfy new alignment or NUMA node, even when
the object is being shrunk.&lt;/p&gt;
&lt;p&gt;This introduced two bugs in the reallocation fallback path:&lt;/p&gt;
&lt;p&gt;1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens
   before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the
   memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new
   allocation.&lt;/p&gt;
&lt;p&gt;2. Buffer overflow during shrinking: When shrinking an object while
   forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.
   However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading
   to an out-of-bounds write.&lt;/p&gt;
&lt;p&gt;The same overflow bug exists in the kvrealloc() fallback path, where the
old bucket size ksize(p) is copied into the new buffer without being
bounded by the new size.&lt;/p&gt;
&lt;p&gt;A simple reproducer:&lt;/p&gt;
&lt;p&gt;// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW
	while (1) {
		void *p = kmalloc(128, GFP_KERNEL);
		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
		kfree(p);
	}&lt;/p&gt;
&lt;p&gt;demonstrates the issue:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130&lt;/p&gt;
&lt;p&gt;Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
   memcpy_orig+0x68/0x130
   krea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;slub: fix data loss and overflow in krealloc()&lt;/p&gt;
&lt;p&gt;Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in
k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the
original object does not satisfy new alignment or NUMA node, even when
the object is being shrunk.&lt;/p&gt;
&lt;p&gt;This introduced two bugs in the reallocation fallback path:&lt;/p&gt;
&lt;p&gt;1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens
   before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the
   memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new
   allocation.&lt;/p&gt;
&lt;p&gt;2. Buffer overflow during shrinking: When shrinking an object while
   forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.
   However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading
   to an out-of-bounds write.&lt;/p&gt;
&lt;p&gt;The same overflow bug exists in the kvrealloc() fallback path, where the
old bucket size ksize(p) is copied into the new buffer without being
bounded by the new size.&lt;/p&gt;
&lt;p&gt;A simple reproducer:&lt;/p&gt;
&lt;p&gt;// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW
	while (1) {
		void *p = kmalloc(128, GFP_KERNEL);
		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
		kfree(p);
	}&lt;/p&gt;
&lt;p&gt;demonstrates the issue:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130&lt;/p&gt;
&lt;p&gt;Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
   memcpy_orig+0x68/0x130
   krea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45990</guid>
    </item>
    <item>
      <title>GHSA-q4r9-vxp8-26x5</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q4r9-vxp8-26x5</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;slub: fix data loss and overflow in krealloc()&lt;/p&gt;
&lt;p&gt;Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in
k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the
original object does not satisfy new alignment or NUMA node, even when
the object is being shrunk.&lt;/p&gt;
&lt;p&gt;This introduced two bugs in the reallocation fallback path:&lt;/p&gt;
&lt;p&gt;1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens
   before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the
   memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new
   allocation.&lt;/p&gt;
&lt;p&gt;2. Buffer overflow during shrinking: When shrinking an object while
   forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.
   However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading
   to an out-of-bounds write.&lt;/p&gt;
&lt;p&gt;The same overflow bug exists in the kvrealloc() fallback path, where the
old bucket size ksize(p) is copied into the new buffer without being
bounded by the new size.&lt;/p&gt;
&lt;p&gt;A simple reproducer:&lt;/p&gt;
&lt;p&gt;// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW
	while (1) {
		void *p = kmalloc(128, GFP_KERNEL);
		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
		kfree(p);
	}&lt;/p&gt;
&lt;p&gt;demonstrates the issue:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130&lt;/p&gt;
&lt;p&gt;Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
   memcpy_orig+0x68/0x130
   krea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;slub: fix data loss and overflow in krealloc()&lt;/p&gt;
&lt;p&gt;Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in
k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the
original object does not satisfy new alignment or NUMA node, even when
the object is being shrunk.&lt;/p&gt;
&lt;p&gt;This introduced two bugs in the reallocation fallback path:&lt;/p&gt;
&lt;p&gt;1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens
   before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the
   memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new
   allocation.&lt;/p&gt;
&lt;p&gt;2. Buffer overflow during shrinking: When shrinking an object while
   forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.
   However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading
   to an out-of-bounds write.&lt;/p&gt;
&lt;p&gt;The same overflow bug exists in the kvrealloc() fallback path, where the
old bucket size ksize(p) is copied into the new buffer without being
bounded by the new size.&lt;/p&gt;
&lt;p&gt;A simple reproducer:&lt;/p&gt;
&lt;p&gt;// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW
	while (1) {
		void *p = kmalloc(128, GFP_KERNEL);
		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
		kfree(p);
	}&lt;/p&gt;
&lt;p&gt;demonstrates the issue:&lt;/p&gt;
&lt;p&gt;==================================================================
  BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130&lt;/p&gt;
&lt;p&gt;Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
   memcpy_orig+0x68/0x130
   krea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q4r9-vxp8-26x5</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10954-1 — kernel-devel-7.0.11-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-45990</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45990</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 98 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: slub: fix data loss and overflow in krealloc() Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens    before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the    memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new    allocation. 2. Buffer overflow during shrinking: When shrinking an object while    forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.    However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading    to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: 	// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW 	while (1) { 		void *p = kmalloc(128, GFP_KERNEL); 		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); 		kfree(p); 	} demonstrates the issue:   ==================================================================   BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130   Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):    memcpy_orig+0x68/0x130    krealloc_node_a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 98 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: slub: fix data loss and overflow in krealloc() Commit 2cd8231796b5 (&amp;#34;mm/slub: allow to set node and align in k[v]realloc&amp;#34;) introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk. This introduced two bugs in the reallocation fallback path: 1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens    before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the    memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new    allocation. 2. Buffer overflow during shrinking: When shrinking an object while    forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.    However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading    to an out-of-bounds write. The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size. A simple reproducer: 	// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW 	while (1) { 		void *p = kmalloc(128, GFP_KERNEL); 		p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); 		kfree(p); 	} demonstrates the issue:   ==================================================================   BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130   Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):    memcpy_orig+0x68/0x130    krealloc_node_a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45990</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
