<?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:52:26 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-43121</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43121</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-43121</guid>
    </item>
    <item>
      <title>EUVD-2026-315758</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315758</link>
      <description>EUVD-2026-315758</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315758</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43121</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43121</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;io_uring/zcrx: fix user_ref race between scrub and refill paths&lt;/p&gt;
&lt;p&gt;The io_zcrx_put_niov_uref() function uses a non-atomic
check-then-decrement pattern (atomic_read followed by separate
atomic_dec) to manipulate user_refs. This is serialized against other
callers by rq_lock, but io_zcrx_scrub() modifies the same counter with
atomic_xchg() WITHOUT holding rq_lock.&lt;/p&gt;
&lt;p&gt;On SMP systems, the following race exists:&lt;/p&gt;
&lt;p&gt;CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)
  put_niov_uref:
    atomic_read(uref) - 1
    // window opens
                                        atomic_xchg(uref, 0) - 1
                                        return_niov_freelist(niov) [PUSH #1]
    // window closes
    atomic_dec(uref) - wraps to -1
    returns true
    return_niov(niov)
    return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE]&lt;/p&gt;
&lt;p&gt;The same niov is pushed to the freelist twice, causing free_count to
exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds
write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent
slab object.&lt;/p&gt;
&lt;p&gt;Fix this by replacing the non-atomic read-then-dec in
io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically
tests and decrements user_refs. This makes the operation safe against
concurrent atomic_xchg from scrub without requiring scrub to acquire
rq_lock.&lt;/p&gt;
&lt;p&gt;[pavel: removed a warning and a comment]&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;io_uring/zcrx: fix user_ref race between scrub and refill paths&lt;/p&gt;
&lt;p&gt;The io_zcrx_put_niov_uref() function uses a non-atomic
check-then-decrement pattern (atomic_read followed by separate
atomic_dec) to manipulate user_refs. This is serialized against other
callers by rq_lock, but io_zcrx_scrub() modifies the same counter with
atomic_xchg() WITHOUT holding rq_lock.&lt;/p&gt;
&lt;p&gt;On SMP systems, the following race exists:&lt;/p&gt;
&lt;p&gt;CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)
  put_niov_uref:
    atomic_read(uref) - 1
    // window opens
                                        atomic_xchg(uref, 0) - 1
                                        return_niov_freelist(niov) [PUSH #1]
    // window closes
    atomic_dec(uref) - wraps to -1
    returns true
    return_niov(niov)
    return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE]&lt;/p&gt;
&lt;p&gt;The same niov is pushed to the freelist twice, causing free_count to
exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds
write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent
slab object.&lt;/p&gt;
&lt;p&gt;Fix this by replacing the non-atomic read-then-dec in
io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically
tests and decrements user_refs. This makes the operation safe against
concurrent atomic_xchg from scrub without requiring scrub to acquire
rq_lock.&lt;/p&gt;
&lt;p&gt;[pavel: removed a warning and a comment]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43121</guid>
    </item>
    <item>
      <title>GHSA-77p3-mmmp-fjj2</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-77p3-mmmp-fjj2</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;io_uring/zcrx: fix user_ref race between scrub and refill paths&lt;/p&gt;
&lt;p&gt;The io_zcrx_put_niov_uref() function uses a non-atomic
check-then-decrement pattern (atomic_read followed by separate
atomic_dec) to manipulate user_refs. This is serialized against other
callers by rq_lock, but io_zcrx_scrub() modifies the same counter with
atomic_xchg() WITHOUT holding rq_lock.&lt;/p&gt;
&lt;p&gt;On SMP systems, the following race exists:&lt;/p&gt;
&lt;p&gt;CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)
  put_niov_uref:
    atomic_read(uref) - 1
    // window opens
                                        atomic_xchg(uref, 0) - 1
                                        return_niov_freelist(niov) [PUSH #1]
    // window closes
    atomic_dec(uref) - wraps to -1
    returns true
    return_niov(niov)
    return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE]&lt;/p&gt;
&lt;p&gt;The same niov is pushed to the freelist twice, causing free_count to
exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds
write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent
slab object.&lt;/p&gt;
&lt;p&gt;Fix this by replacing the non-atomic read-then-dec in
io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically
tests and decrements user_refs. This makes the operation safe against
concurrent atomic_xchg from scrub without requiring scrub to acquire
rq_lock.&lt;/p&gt;
&lt;p&gt;[pavel: removed a warning and a comment]&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;io_uring/zcrx: fix user_ref race between scrub and refill paths&lt;/p&gt;
&lt;p&gt;The io_zcrx_put_niov_uref() function uses a non-atomic
check-then-decrement pattern (atomic_read followed by separate
atomic_dec) to manipulate user_refs. This is serialized against other
callers by rq_lock, but io_zcrx_scrub() modifies the same counter with
atomic_xchg() WITHOUT holding rq_lock.&lt;/p&gt;
&lt;p&gt;On SMP systems, the following race exists:&lt;/p&gt;
&lt;p&gt;CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)
  put_niov_uref:
    atomic_read(uref) - 1
    // window opens
                                        atomic_xchg(uref, 0) - 1
                                        return_niov_freelist(niov) [PUSH #1]
    // window closes
    atomic_dec(uref) - wraps to -1
    returns true
    return_niov(niov)
    return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE]&lt;/p&gt;
&lt;p&gt;The same niov is pushed to the freelist twice, causing free_count to
exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds
write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent
slab object.&lt;/p&gt;
&lt;p&gt;Fix this by replacing the non-atomic read-then-dec in
io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically
tests and decrements user_refs. This makes the operation safe against
concurrent atomic_xchg from scrub without requiring scrub to acquire
rq_lock.&lt;/p&gt;
&lt;p&gt;[pavel: removed a warning and a comment]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-77p3-mmmp-fjj2</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43121</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43121</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 103 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix user_ref race between scrub and refill paths The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock. On SMP systems, the following race exists:   CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)   put_niov_uref:     atomic_read(uref) - 1     // window opens                                         atomic_xchg(uref, 0) - 1                                         return_niov_freelist(niov) [PUSH #1]     // window closes     atomic_dec(uref) - wraps to -1     returns true     return_niov(niov)     return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE] The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent slab object. Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock. [pavel: removed a warning and a comment]&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 103 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix user_ref race between scrub and refill paths The io_zcrx_put_niov_uref() function uses a non-atomic check-then-decrement pattern (atomic_read followed by separate atomic_dec) to manipulate user_refs. This is serialized against other callers by rq_lock, but io_zcrx_scrub() modifies the same counter with atomic_xchg() WITHOUT holding rq_lock. On SMP systems, the following race exists:   CPU0 (refill, holds rq_lock)          CPU1 (scrub, no rq_lock)   put_niov_uref:     atomic_read(uref) - 1     // window opens                                         atomic_xchg(uref, 0) - 1                                         return_niov_freelist(niov) [PUSH #1]     // window closes     atomic_dec(uref) - wraps to -1     returns true     return_niov(niov)     return_niov_freelist(niov)           [PUSH #2: DOUBLE-FREE] The same niov is pushed to the freelist twice, causing free_count to exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds write (a u32 value) past the kvmalloc&amp;#39;d freelist array into the adjacent slab object. Fix this by replacing the non-atomic read-then-dec in io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically tests and decrements user_refs. This makes the operation safe against concurrent atomic_xchg from scrub without requiring scrub to acquire rq_lock. [pavel: removed a warning and a comment]&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43121</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1405 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1405</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht spezifizierte Angriffe durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht spezifizierte Angriffe durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1405</guid>
    </item>
  </channel>
</rss>
