<?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 05:33:46 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12197</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12197</link>
      <description>bdu:2026-12197</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12197</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-45895</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45895</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-45895</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-321815</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-321815</link>
      <description>EUVD-2026-321815</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-321815</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45895</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45895</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;quota: fix livelock between quotactl and freeze_super&lt;/p&gt;
&lt;p&gt;When a filesystem is frozen, quotactl_block() enters a retry loop
waiting for the filesystem to thaw. It acquires s_umount, checks the
freeze state, drops s_umount and uses sb_start_write() - sb_end_write()
pair to wait for the unfreeze.&lt;/p&gt;
&lt;p&gt;However, this retry loop can trigger a livelock issue, specifically on
kernels with preemption disabled.&lt;/p&gt;
&lt;p&gt;The mechanism is as follows:
1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
2. sb_wait_write() calls percpu_down_write(), which initiates
   synchronize_rcu().
3. Simultaneously, quotactl_block() spins in its retry loop, immediately
   executing the sb_start_write() - sb_end_write() pair.
4. Because the kernel is non-preemptible and the loop contains no
   scheduling points, quotactl_block() never yields the CPU. This
   prevents that CPU from reaching an RCU quiescent state.
5. synchronize_rcu() in the freezer thread waits indefinitely for the
   quotactl_block() CPU to report a quiescent state.
6. quotactl_block() spins indefinitely waiting for the freezer to
   advance, which it cannot do as it is blocked on the RCU sync.&lt;/p&gt;
&lt;p&gt;This results in a hang of the freezer process and 100% CPU usage by the
quota process.&lt;/p&gt;
&lt;p&gt;While this can occur intermittently on multi-core systems, it is
reliably reproducing on a node with the following script, running both
the freezer and the quota toggle on the same CPU:…&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;quota: fix livelock between quotactl and freeze_super&lt;/p&gt;
&lt;p&gt;When a filesystem is frozen, quotactl_block() enters a retry loop
waiting for the filesystem to thaw. It acquires s_umount, checks the
freeze state, drops s_umount and uses sb_start_write() - sb_end_write()
pair to wait for the unfreeze.&lt;/p&gt;
&lt;p&gt;However, this retry loop can trigger a livelock issue, specifically on
kernels with preemption disabled.&lt;/p&gt;
&lt;p&gt;The mechanism is as follows:
1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
2. sb_wait_write() calls percpu_down_write(), which initiates
   synchronize_rcu().
3. Simultaneously, quotactl_block() spins in its retry loop, immediately
   executing the sb_start_write() - sb_end_write() pair.
4. Because the kernel is non-preemptible and the loop contains no
   scheduling points, quotactl_block() never yields the CPU. This
   prevents that CPU from reaching an RCU quiescent state.
5. synchronize_rcu() in the freezer thread waits indefinitely for the
   quotactl_block() CPU to report a quiescent state.
6. quotactl_block() spins indefinitely waiting for the freezer to
   advance, which it cannot do as it is blocked on the RCU sync.&lt;/p&gt;
&lt;p&gt;This results in a hang of the freezer process and 100% CPU usage by the
quota process.&lt;/p&gt;
&lt;p&gt;While this can occur intermittently on multi-core systems, it is
reliably reproducing on a node with the following script, running both
the freezer and the quota toggle on the same CPU:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45895</guid>
    </item>
    <item>
      <title>GHSA-c6wv-8c38-r975</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c6wv-8c38-r975</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;quota: fix livelock between quotactl and freeze_super&lt;/p&gt;
&lt;p&gt;When a filesystem is frozen, quotactl_block() enters a retry loop
waiting for the filesystem to thaw. It acquires s_umount, checks the
freeze state, drops s_umount and uses sb_start_write() - sb_end_write()
pair to wait for the unfreeze.&lt;/p&gt;
&lt;p&gt;However, this retry loop can trigger a livelock issue, specifically on
kernels with preemption disabled.&lt;/p&gt;
&lt;p&gt;The mechanism is as follows:
1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
2. sb_wait_write() calls percpu_down_write(), which initiates
   synchronize_rcu().
3. Simultaneously, quotactl_block() spins in its retry loop, immediately
   executing the sb_start_write() - sb_end_write() pair.
4. Because the kernel is non-preemptible and the loop contains no
   scheduling points, quotactl_block() never yields the CPU. This
   prevents that CPU from reaching an RCU quiescent state.
5. synchronize_rcu() in the freezer thread waits indefinitely for the
   quotactl_block() CPU to report a quiescent state.
6. quotactl_block() spins indefinitely waiting for the freezer to
   advance, which it cannot do as it is blocked on the RCU sync.&lt;/p&gt;
&lt;p&gt;This results in a hang of the freezer process and 100% CPU usage by the
quota process.&lt;/p&gt;
&lt;p&gt;While this can occur intermittently on multi-core systems, it is
reliably reproducing on a node with the following script, running both
the freezer and the quota toggle on the same CPU:…&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;quota: fix livelock between quotactl and freeze_super&lt;/p&gt;
&lt;p&gt;When a filesystem is frozen, quotactl_block() enters a retry loop
waiting for the filesystem to thaw. It acquires s_umount, checks the
freeze state, drops s_umount and uses sb_start_write() - sb_end_write()
pair to wait for the unfreeze.&lt;/p&gt;
&lt;p&gt;However, this retry loop can trigger a livelock issue, specifically on
kernels with preemption disabled.&lt;/p&gt;
&lt;p&gt;The mechanism is as follows:
1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().
2. sb_wait_write() calls percpu_down_write(), which initiates
   synchronize_rcu().
3. Simultaneously, quotactl_block() spins in its retry loop, immediately
   executing the sb_start_write() - sb_end_write() pair.
4. Because the kernel is non-preemptible and the loop contains no
   scheduling points, quotactl_block() never yields the CPU. This
   prevents that CPU from reaching an RCU quiescent state.
5. synchronize_rcu() in the freezer thread waits indefinitely for the
   quotactl_block() CPU to report a quiescent state.
6. quotactl_block() spins indefinitely waiting for the freezer to
   advance, which it cannot do as it is blocked on the RCU sync.&lt;/p&gt;
&lt;p&gt;This results in a hang of the freezer process and 100% CPU usage by the
quota process.&lt;/p&gt;
&lt;p&gt;While this can occur intermittently on multi-core systems, it is
reliably reproducing on a node with the following script, running both
the freezer and the quota toggle on the same CPU:…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c6wv-8c38-r975</guid>
    </item>
    <item>
      <title>OESA-2026-2675 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2675</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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/i915/gt: Fix timeline left held on VMA alloc error&lt;/p&gt;
&lt;p&gt;The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;4&amp;amp;gt; [239.330153] ------------[ cut here ]------------
&amp;amp;lt;4&amp;amp;gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&amp;amp;gt;mm.shrink_count)
&amp;amp;lt;4&amp;amp;gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330942] Call Trace:
&amp;amp;lt;4&amp;amp;gt; [239.330944]  &amp;amp;lt;TASK&amp;amp;gt;
&amp;amp;lt;4&amp;amp;gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90
&amp;amp;lt;4&amp;amp;gt; [239.331494]  devm_action_release+0x15/0x30
&amp;amp;lt;4&amp;amp;gt; [239.331504]  release_nodes+0x3d/0x120
&amp;amp;lt;4&amp;amp;gt; [239.331517]  devres_release_all+0x96/0xd0
&amp;amp;lt;4&amp;amp;gt; [239.331533]  device_unbind_cleanup+0x12/0x80
&amp;amp;lt;4&amp;amp;gt; [239.331543]  device_release_driver_internal+0x23a/0x280
&amp;amp;lt;4&amp;amp;gt; [239.331550]  ? bus_find_device+0xa5/0xe0
&amp;amp;lt;4&amp;amp;gt; [239.331563]  device_driver_detach+0x14/0x20
...
&amp;amp;lt;4&amp;amp;gt; [357.719679] ---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;If the test also unloads the i915 module then that&amp;amp;apos;s followed with:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;3&amp;amp;gt; [357.787478] ===…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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/i915/gt: Fix timeline left held on VMA alloc error&lt;/p&gt;
&lt;p&gt;The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;4&amp;amp;gt; [239.330153] ------------[ cut here ]------------
&amp;amp;lt;4&amp;amp;gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-&amp;amp;gt;mm.shrink_count)
&amp;amp;lt;4&amp;amp;gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
...
&amp;amp;lt;4&amp;amp;gt; [239.330942] Call Trace:
&amp;amp;lt;4&amp;amp;gt; [239.330944]  &amp;amp;lt;TASK&amp;amp;gt;
&amp;amp;lt;4&amp;amp;gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]
&amp;amp;lt;4&amp;amp;gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90
&amp;amp;lt;4&amp;amp;gt; [239.331494]  devm_action_release+0x15/0x30
&amp;amp;lt;4&amp;amp;gt; [239.331504]  release_nodes+0x3d/0x120
&amp;amp;lt;4&amp;amp;gt; [239.331517]  devres_release_all+0x96/0xd0
&amp;amp;lt;4&amp;amp;gt; [239.331533]  device_unbind_cleanup+0x12/0x80
&amp;amp;lt;4&amp;amp;gt; [239.331543]  device_release_driver_internal+0x23a/0x280
&amp;amp;lt;4&amp;amp;gt; [239.331550]  ? bus_find_device+0xa5/0xe0
&amp;amp;lt;4&amp;amp;gt; [239.331563]  device_driver_detach+0x14/0x20
...
&amp;amp;lt;4&amp;amp;gt; [357.719679] ---[ end trace 0000000000000000 ]---&lt;/p&gt;
&lt;p&gt;If the test also unloads the i915 module then that&amp;amp;apos;s followed with:&lt;/p&gt;
&lt;p&gt;&amp;amp;lt;3&amp;amp;gt; [357.787478] ===…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2675</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21555-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-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/opensuse-su-2026:21555-1</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-45895</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45895</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 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: quota: fix livelock between quotactl and freeze_super When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates    synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately    executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no    scheduling points, quotactl_block() never yields the CPU. This    prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the    quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to    advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:   # mkf…&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 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: quota: fix livelock between quotactl and freeze_super When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze. However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled. The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates    synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately    executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no    scheduling points, quotactl_block() never yields the CPU. This    prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the    quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to    advance, which it cannot do as it is blocked on the RCU sync. This results in a hang of the freezer process and 100% CPU usage by the quota process. While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:   # mkf…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45895</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>
