<?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 20:33:07 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-10442</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-10442</link>
      <description>bdu:2026-10442</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-10442</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-64600</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-64600</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-64600</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>ESSA-2026:0154 — Important: kernel update</title>
      <link>https://cve.radiocsirt.org/vuln/essa-2026:0154</link>
      <description>&lt;p&gt;Important: kernel update&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Important: kernel update&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/essa-2026:0154</guid>
    </item>
    <item>
      <title>EUVD-2026-353450</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353450</link>
      <description>EUVD-2026-353450</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353450</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64600</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64600</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfs: resample the data fork mapping after cycling ILOCK&lt;/p&gt;
&lt;p&gt;xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,
a data fork mapping, and a cow fork mapping.  Unfortunately, these two
helpers cycle the ILOCK to grab a transaction, which means that the
mappings are stale as soon as we reacquire the ILOCK.  Currently we
refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but
we don&amp;#39;t refresh the data fork mapping beforehand, which means that the
xfs_bmap_trim_cow in that function queries the refcount btree about the
wrong physical blocks and returns an inaccurate value in *shared.&lt;/p&gt;
&lt;p&gt;If *shared is now false, the directio write proceeds with a stale data
fork mapping.  Fix this by querying the data fork mapping if the
sequence counter changes across the ILOCK cycle.&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;xfs: resample the data fork mapping after cycling ILOCK&lt;/p&gt;
&lt;p&gt;xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,
a data fork mapping, and a cow fork mapping.  Unfortunately, these two
helpers cycle the ILOCK to grab a transaction, which means that the
mappings are stale as soon as we reacquire the ILOCK.  Currently we
refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but
we don&amp;#39;t refresh the data fork mapping beforehand, which means that the
xfs_bmap_trim_cow in that function queries the refcount btree about the
wrong physical blocks and returns an inaccurate value in *shared.&lt;/p&gt;
&lt;p&gt;If *shared is now false, the directio write proceeds with a stale data
fork mapping.  Fix this by querying the data fork mapping if the
sequence counter changes across the ILOCK cycle.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-64600</guid>
    </item>
    <item>
      <title>GHSA-6p99-w6f4-qcvq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6p99-w6f4-qcvq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfs: resample the data fork mapping after cycling ILOCK&lt;/p&gt;
&lt;p&gt;xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,
a data fork mapping, and a cow fork mapping.  Unfortunately, these two
helpers cycle the ILOCK to grab a transaction, which means that the
mappings are stale as soon as we reacquire the ILOCK.  Currently we
refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but
we don&amp;#39;t refresh the data fork mapping beforehand, which means that the
xfs_bmap_trim_cow in that function queries the refcount btree about the
wrong physical blocks and returns an inaccurate value in *shared.&lt;/p&gt;
&lt;p&gt;If *shared is now false, the directio write proceeds with a stale data
fork mapping.  Fix this by querying the data fork mapping if the
sequence counter changes across the ILOCK cycle.&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;xfs: resample the data fork mapping after cycling ILOCK&lt;/p&gt;
&lt;p&gt;xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode,
a data fork mapping, and a cow fork mapping.  Unfortunately, these two
helpers cycle the ILOCK to grab a transaction, which means that the
mappings are stale as soon as we reacquire the ILOCK.  Currently we
refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but
we don&amp;#39;t refresh the data fork mapping beforehand, which means that the
xfs_bmap_trim_cow in that function queries the refcount btree about the
wrong physical blocks and returns an inaccurate value in *shared.&lt;/p&gt;
&lt;p&gt;If *shared is now false, the directio write proceeds with a stale data
fork mapping.  Fix this by querying the data fork mapping if the
sequence counter changes across the ILOCK cycle.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6p99-w6f4-qcvq</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-64600 — xfs: resample the data fork mapping after cycling ILOCK</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-64600</link>
      <description>msrc_CVE-2026-64600</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-64600</guid>
    </item>
    <item>
      <title>OESA-2026-3205 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3205</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;Arm C1-Ultra, C1-Premium, Neoverse V3 &amp;amp;amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 &amp;amp;amp; X1C, Cortex-A710, Cortex-A78, A78AE &amp;amp;amp; A78C, Cortex-A77, Cortex-A76 &amp;amp;amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: ac97: fix a double free in snd_ac97_controller_register()&lt;/p&gt;
&lt;p&gt;If ac97_add_adapter() fails, put_device() is the correct way to drop
the device reference. kfree() is not required.
Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do
the cleanup.&lt;/p&gt;
&lt;p&gt;Found by code review.(CVE-2025-71192)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak&lt;/p&gt;
&lt;p&gt;Fix similar memory leak as in commit 7352e1d5932a (&amp;amp;quot;can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory leak&amp;amp;quot;).&lt;/p&gt;
&lt;p&gt;In ems_usb_open(), the URBs for USB-in transfers are allocated, added to
the dev-&amp;amp;gt;rx_submitted anchor and submitted. In the complete callback
ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In
ems_usb_close() the URBs are freed by calling
usb_kill_anchored_urbs(&amp;amp;amp;dev-&amp;amp;gt;rx_submitted).&lt;/p&gt;
&lt;p&gt;However, this does not take into account that the USB framework unanchors
the URB before the complete function is called. This means that once a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.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;Arm C1-Ultra, C1-Premium, Neoverse V3 &amp;amp;amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 &amp;amp;amp; X1C, Cortex-A710, Cortex-A78, A78AE &amp;amp;amp; A78C, Cortex-A77, Cortex-A76 &amp;amp;amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ALSA: ac97: fix a double free in snd_ac97_controller_register()&lt;/p&gt;
&lt;p&gt;If ac97_add_adapter() fails, put_device() is the correct way to drop
the device reference. kfree() is not required.
Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do
the cleanup.&lt;/p&gt;
&lt;p&gt;Found by code review.(CVE-2025-71192)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak&lt;/p&gt;
&lt;p&gt;Fix similar memory leak as in commit 7352e1d5932a (&amp;amp;quot;can: gs_usb:
gs_usb_receive_bulk_callback(): fix URB memory leak&amp;amp;quot;).&lt;/p&gt;
&lt;p&gt;In ems_usb_open(), the URBs for USB-in transfers are allocated, added to
the dev-&amp;amp;gt;rx_submitted anchor and submitted. In the complete callback
ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In
ems_usb_close() the URBs are freed by calling
usb_kill_anchored_urbs(&amp;amp;amp;dev-&amp;amp;gt;rx_submitted).&lt;/p&gt;
&lt;p&gt;However, this does not take into account that the USB framework unanchors
the URB before the complete function is called. This means that once a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3205</guid>
    </item>
    <item>
      <title>RHBA-2026:39321 — Red Hat Bug Fix Advisory: kernel  update</title>
      <link>https://cve.radiocsirt.org/vuln/rhba-2026:39321</link>
      <description>&lt;p&gt;kernel: XFS data corruption using reflink&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: XFS data corruption using reflink&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhba-2026:39321</guid>
    </item>
    <item>
      <title>RLBA-2026:39332 — Important:kernel bug fix and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlba-2026:39332</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:9: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* XFS data corruption using reflink [rhel-9.8.z] (JIRA:Rocky Linux-193937)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:9: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* XFS data corruption using reflink [rhel-9.8.z] (JIRA:Rocky Linux-193937)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rlba-2026:39332</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23066-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23066-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:23066-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64600</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64600</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping.  Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK.  Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don&amp;#39;t refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping.  Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 239 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping.  Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK.  Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don&amp;#39;t refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping.  Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64600</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2481 — Linux Kernel: Schwachstelle ermöglicht Privilegieneskalation</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2481</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann eine Schwachstelle im Linux Kernel ausnutzen, um seine Privilegien zu erhöhen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann eine Schwachstelle im Linux Kernel ausnutzen, um seine Privilegien zu erhöhen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2481</guid>
    </item>
  </channel>
</rss>
