<?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 19:49:46 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-31716</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31716</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-31716</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-347777</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347777</link>
      <description>EUVD-2026-347777</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347777</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31716</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31716</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check&lt;/p&gt;
&lt;p&gt;check_file_record() validates rec-&amp;gt;total against the record size but
never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read
rec-&amp;gt;used from disk and use it to compute memmove lengths:&lt;/p&gt;
&lt;p&gt;DeleteAttribute:    memmove(attr, ..., used - asize - roff)
  CreateAttribute:    memmove(..., attr, used - roff)
  change_attr_size:   memmove(..., used - PtrOffset(rec, next))&lt;/p&gt;
&lt;p&gt;When rec-&amp;gt;used is smaller than the offset of a validated attribute, or
larger than the record size, these subtractions can underflow allowing
us to copy huge amounts of memory in to a 4kb buffer, generally
considered a bad idea overall.&lt;/p&gt;
&lt;p&gt;This requires a corrupted filesystem, which isn&amp;#39;t a threat model the
kernel really needs to worry about, but checking for such an obvious
out-of-bounds value is good to keep things robust, especially on journal
replay&lt;/p&gt;
&lt;p&gt;Fix this up by bounding rec-&amp;gt;used correctly.&lt;/p&gt;
&lt;p&gt;This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds
read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this
same switch statement.&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;fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check&lt;/p&gt;
&lt;p&gt;check_file_record() validates rec-&amp;gt;total against the record size but
never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read
rec-&amp;gt;used from disk and use it to compute memmove lengths:&lt;/p&gt;
&lt;p&gt;DeleteAttribute:    memmove(attr, ..., used - asize - roff)
  CreateAttribute:    memmove(..., attr, used - roff)
  change_attr_size:   memmove(..., used - PtrOffset(rec, next))&lt;/p&gt;
&lt;p&gt;When rec-&amp;gt;used is smaller than the offset of a validated attribute, or
larger than the record size, these subtractions can underflow allowing
us to copy huge amounts of memory in to a 4kb buffer, generally
considered a bad idea overall.&lt;/p&gt;
&lt;p&gt;This requires a corrupted filesystem, which isn&amp;#39;t a threat model the
kernel really needs to worry about, but checking for such an obvious
out-of-bounds value is good to keep things robust, especially on journal
replay&lt;/p&gt;
&lt;p&gt;Fix this up by bounding rec-&amp;gt;used correctly.&lt;/p&gt;
&lt;p&gt;This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds
read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this
same switch statement.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31716</guid>
    </item>
    <item>
      <title>GHSA-vw9p-6cf6-hxfh</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-vw9p-6cf6-hxfh</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check&lt;/p&gt;
&lt;p&gt;check_file_record() validates rec-&amp;gt;total against the record size but
never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read
rec-&amp;gt;used from disk and use it to compute memmove lengths:&lt;/p&gt;
&lt;p&gt;DeleteAttribute:    memmove(attr, ..., used - asize - roff)
  CreateAttribute:    memmove(..., attr, used - roff)
  change_attr_size:   memmove(..., used - PtrOffset(rec, next))&lt;/p&gt;
&lt;p&gt;When rec-&amp;gt;used is smaller than the offset of a validated attribute, or
larger than the record size, these subtractions can underflow allowing
us to copy huge amounts of memory in to a 4kb buffer, generally
considered a bad idea overall.&lt;/p&gt;
&lt;p&gt;This requires a corrupted filesystem, which isn&amp;#39;t a threat model the
kernel really needs to worry about, but checking for such an obvious
out-of-bounds value is good to keep things robust, especially on journal
replay&lt;/p&gt;
&lt;p&gt;Fix this up by bounding rec-&amp;gt;used correctly.&lt;/p&gt;
&lt;p&gt;This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds
read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this
same switch statement.&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;fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check&lt;/p&gt;
&lt;p&gt;check_file_record() validates rec-&amp;gt;total against the record size but
never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read
rec-&amp;gt;used from disk and use it to compute memmove lengths:&lt;/p&gt;
&lt;p&gt;DeleteAttribute:    memmove(attr, ..., used - asize - roff)
  CreateAttribute:    memmove(..., attr, used - roff)
  change_attr_size:   memmove(..., used - PtrOffset(rec, next))&lt;/p&gt;
&lt;p&gt;When rec-&amp;gt;used is smaller than the offset of a validated attribute, or
larger than the record size, these subtractions can underflow allowing
us to copy huge amounts of memory in to a 4kb buffer, generally
considered a bad idea overall.&lt;/p&gt;
&lt;p&gt;This requires a corrupted filesystem, which isn&amp;#39;t a threat model the
kernel really needs to worry about, but checking for such an obvious
out-of-bounds value is good to keep things robust, especially on journal
replay&lt;/p&gt;
&lt;p&gt;Fix this up by bounding rec-&amp;gt;used correctly.&lt;/p&gt;
&lt;p&gt;This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds
read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this
same switch statement.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-vw9p-6cf6-hxfh</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:10793-1 — kernel-devel-7.0.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10793-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10793-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31716</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31716</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 191 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check check_file_record() validates rec-&amp;gt;total against the record size but never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read rec-&amp;gt;used from disk and use it to compute memmove lengths:   DeleteAttribute:    memmove(attr, ..., used - asize - roff)   CreateAttribute:    memmove(..., attr, used - roff)   change_attr_size:   memmove(..., used - PtrOffset(rec, next)) When rec-&amp;gt;used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn&amp;#39;t a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec-&amp;gt;used correctly. This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this same switch statement.&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 191 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec-&amp;gt;used in journal-replay file record check check_file_record() validates rec-&amp;gt;total against the record size but never validates rec-&amp;gt;used.  The do_action() journal-replay handlers read rec-&amp;gt;used from disk and use it to compute memmove lengths:   DeleteAttribute:    memmove(attr, ..., used - asize - roff)   CreateAttribute:    memmove(..., attr, used - roff)   change_attr_size:   memmove(..., used - PtrOffset(rec, next)) When rec-&amp;gt;used is smaller than the offset of a validated attribute, or larger than the record size, these subtractions can underflow allowing us to copy huge amounts of memory in to a 4kb buffer, generally considered a bad idea overall. This requires a corrupted filesystem, which isn&amp;#39;t a threat model the kernel really needs to worry about, but checking for such an obvious out-of-bounds value is good to keep things robust, especially on journal replay Fix this up by bounding rec-&amp;gt;used correctly. This is much like commit b2bc7c44ed17 (&amp;#34;fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot&amp;#34;) which checked different values in this same switch statement.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31716</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1346 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1346</link>
      <description>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Root-Rechte zu erlangen, um Sicherheitsmechanismen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder Auswirkungen unbestimmter Art zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Root-Rechte zu erlangen, um Sicherheitsmechanismen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder Auswirkungen unbestimmter Art zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1346</guid>
    </item>
  </channel>
</rss>
