<?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>Fri, 02 Oct 2026 17:17:09 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-64322</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-64322</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-64322</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0982 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0982</link>
      <description>certfr-2026-avi-0982</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0982</guid>
    </item>
    <item>
      <title>EUVD-2026-353233</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353233</link>
      <description>EUVD-2026-353233</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353233</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64322</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64322</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;udf: validate sparing table length as an entry count, not a byte count&lt;/p&gt;
&lt;p&gt;udf_load_sparable_map() accepts a sparing table when&lt;/p&gt;
&lt;p&gt;sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize&lt;/p&gt;
&lt;p&gt;is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block.  But the table is walked as an array of 8-byte
sparingEntry elements:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) {
		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i];
		... entry-&amp;gt;origLocation ...
	}&lt;/p&gt;
&lt;p&gt;in udf_get_pblock_spar15() and udf_relocate_blocks().  A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block.  On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds
write.&lt;/p&gt;
&lt;p&gt;Validate reallocationTableLen as the entry count it is, with
struct_size().&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;udf: validate sparing table length as an entry count, not a byte count&lt;/p&gt;
&lt;p&gt;udf_load_sparable_map() accepts a sparing table when&lt;/p&gt;
&lt;p&gt;sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize&lt;/p&gt;
&lt;p&gt;is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block.  But the table is walked as an array of 8-byte
sparingEntry elements:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) {
		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i];
		... entry-&amp;gt;origLocation ...
	}&lt;/p&gt;
&lt;p&gt;in udf_get_pblock_spar15() and udf_relocate_blocks().  A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block.  On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds
write.&lt;/p&gt;
&lt;p&gt;Validate reallocationTableLen as the entry count it is, with
struct_size().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-64322</guid>
    </item>
    <item>
      <title>GHSA-r2mg-8x37-x2q4</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-r2mg-8x37-x2q4</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;udf: validate sparing table length as an entry count, not a byte count&lt;/p&gt;
&lt;p&gt;udf_load_sparable_map() accepts a sparing table when&lt;/p&gt;
&lt;p&gt;sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize&lt;/p&gt;
&lt;p&gt;is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block.  But the table is walked as an array of 8-byte
sparingEntry elements:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) {
		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i];
		... entry-&amp;gt;origLocation ...
	}&lt;/p&gt;
&lt;p&gt;in udf_get_pblock_spar15() and udf_relocate_blocks().  A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block.  On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds
write.&lt;/p&gt;
&lt;p&gt;Validate reallocationTableLen as the entry count it is, with
struct_size().&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;udf: validate sparing table length as an entry count, not a byte count&lt;/p&gt;
&lt;p&gt;udf_load_sparable_map() accepts a sparing table when&lt;/p&gt;
&lt;p&gt;sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize&lt;/p&gt;
&lt;p&gt;is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block.  But the table is walked as an array of 8-byte
sparingEntry elements:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) {
		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i];
		... entry-&amp;gt;origLocation ...
	}&lt;/p&gt;
&lt;p&gt;in udf_get_pblock_spar15() and udf_relocate_blocks().  A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block.  On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds
write.&lt;/p&gt;
&lt;p&gt;Validate reallocationTableLen as the entry count it is, with
struct_size().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-r2mg-8x37-x2q4</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-64322 — udf: validate sparing table length as an entry count, not a byte count</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-64322</link>
      <description>msrc_CVE-2026-64322</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-64322</guid>
    </item>
    <item>
      <title>OESA-2026-3317 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3317</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amdgpu: prevent immediate PASID reuse case&lt;/p&gt;
&lt;p&gt;PASID resue could cause interrupt issue when process
immediately runs into hw state left by previous
process exited with the same PASID, it&amp;amp;apos;s possible that
page faults are still pending in the IH ring buffer when
the process exits and frees up its PASID. To prevent the
case, it uses idr cyclic allocator same as kernel pid&amp;amp;apos;s.&lt;/p&gt;
&lt;p&gt;(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;amp;quot;/path/to/dev&amp;amp;quot;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate i…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/amdgpu: prevent immediate PASID reuse case&lt;/p&gt;
&lt;p&gt;PASID resue could cause interrupt issue when process
immediately runs into hw state left by previous
process exited with the same PASID, it&amp;amp;apos;s possible that
page faults are still pending in the IH ring buffer when
the process exits and frees up its PASID. To prevent the
case, it uses idr cyclic allocator same as kernel pid&amp;amp;apos;s.&lt;/p&gt;
&lt;p&gt;(cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)(CVE-2026-31462)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;media: hackrf: fix to not free memory after the device is registered in hackrf_probe()&lt;/p&gt;
&lt;p&gt;In hackrf driver, the following race condition occurs:
```
		CPU0						CPU1
hackrf_probe()
  kzalloc(); // alloc hackrf_dev
  ....
  v4l2_device_register();
  ....
						fd = sys_open(&amp;amp;quot;/path/to/dev&amp;amp;quot;); // open hackrf fd
						....
  v4l2_device_unregister();
  ....
  kfree(); // free hackrf_dev
  ....
						sys_ioctl(fd, ...);
						  v4l2_ioctl();
						    video_is_registered() // UAF!!
						....
						sys_close(fd);
						  v4l2_release() // UAF!!
						    hackrf_video_release()
						      kfree(); // DFB!!
```&lt;/p&gt;
&lt;p&gt;When a V4L2 or video device is unregistered, the device node is removed so
new open() calls are blocked.&lt;/p&gt;
&lt;p&gt;However, file descriptors that are already open-and any in-flight I/O-do
not terminate i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3317</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11476-1 — kernel-devel-7.1.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</link>
      <description>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64322</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64322</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when 	sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block.  But the table is walked as an array of 8-byte sparingEntry elements: 	for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) { 		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i]; 		... entry-&amp;gt;origLocation ... 	} in udf_get_pblock_spar15() and udf_relocate_blocks().  A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block.  On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when 	sizeof(*st) + le16_to_cpu(st-&amp;gt;reallocationTableLen) &amp;gt; sb-&amp;gt;s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block.  But the table is walked as an array of 8-byte sparingEntry elements: 	for (i = 0; i &amp;lt; le16_to_cpu(st-&amp;gt;reallocationTableLen); i++) { 		struct sparingEntry *entry = &amp;amp;st-&amp;gt;mapEntry[i]; 		... entry-&amp;gt;origLocation ... 	} in udf_get_pblock_spar15() and udf_relocate_blocks().  A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N &amp;lt;= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block.  On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st-&amp;gt;mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64322</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2527 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527</guid>
    </item>
  </channel>
</rss>
