<?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 02:38:38 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-89655</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-89655</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-89655</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1253 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</link>
      <description>certfr-2026-avi-1253</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1253</guid>
    </item>
    <item>
      <title>EUVD-2026-367677</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-367677</link>
      <description>EUVD-2026-367677</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-367677</guid>
    </item>
    <item>
      <title>fkie_cve-2026-89655</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-89655</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock&lt;/p&gt;
&lt;p&gt;list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops
i_ceph_lock to send cap messages.  During the unlock window,
handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries
with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free
them via ceph_free_cap_flush() outside any lock.  When the original
thread reacquires i_ceph_lock and the for-loop macro advances via
cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next
on freed memory.&lt;/p&gt;
&lt;p&gt;The race timeline:&lt;/p&gt;
&lt;p&gt;__kick_flushing_caps()              handle_cap_flush_ack()
  -----------------------             -----------------------
  holds i_ceph_lock        &amp;lt;---
  iterates to cf (tid=10)
  prepares FLUSH message
  drops i_ceph_lock        &amp;lt;---
  __send_cap() ── FLUSH(tid=10)
	                              MDS sends FLUSH_ACK(tid=10)
                           ---&amp;gt;       acquires i_ceph_lock
                                      cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),
                                      detaches cf from i_cap_flush_list
                                      drops i_ceph_lock
                                      ceph_free_cap_flush(cf) &amp;lt;- frees it!
  acquires i_ceph_lock     &amp;lt;---
  for-loop advances:
    cf = list_next_entry(cf, i_list)
      -- UAF on freed cf-&amp;gt;i_list.next&lt;/p&gt;
&lt;p&gt;The cf was just sent by __kick_flushing_caps itself via __send_cap().
The M…&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;ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock&lt;/p&gt;
&lt;p&gt;list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops
i_ceph_lock to send cap messages.  During the unlock window,
handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries
with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free
them via ceph_free_cap_flush() outside any lock.  When the original
thread reacquires i_ceph_lock and the for-loop macro advances via
cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next
on freed memory.&lt;/p&gt;
&lt;p&gt;The race timeline:&lt;/p&gt;
&lt;p&gt;__kick_flushing_caps()              handle_cap_flush_ack()
  -----------------------             -----------------------
  holds i_ceph_lock        &amp;lt;---
  iterates to cf (tid=10)
  prepares FLUSH message
  drops i_ceph_lock        &amp;lt;---
  __send_cap() ── FLUSH(tid=10)
	                              MDS sends FLUSH_ACK(tid=10)
                           ---&amp;gt;       acquires i_ceph_lock
                                      cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),
                                      detaches cf from i_cap_flush_list
                                      drops i_ceph_lock
                                      ceph_free_cap_flush(cf) &amp;lt;- frees it!
  acquires i_ceph_lock     &amp;lt;---
  for-loop advances:
    cf = list_next_entry(cf, i_list)
      -- UAF on freed cf-&amp;gt;i_list.next&lt;/p&gt;
&lt;p&gt;The cf was just sent by __kick_flushing_caps itself via __send_cap().
The M…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-89655</guid>
    </item>
    <item>
      <title>GHSA-67r3-hj2c-67vv</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-67r3-hj2c-67vv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock&lt;/p&gt;
&lt;p&gt;list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops
i_ceph_lock to send cap messages.  During the unlock window,
handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries
with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free
them via ceph_free_cap_flush() outside any lock.  When the original
thread reacquires i_ceph_lock and the for-loop macro advances via
cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next
on freed memory.&lt;/p&gt;
&lt;p&gt;The race timeline:&lt;/p&gt;
&lt;p&gt;__kick_flushing_caps()              handle_cap_flush_ack()
  -----------------------             -----------------------
  holds i_ceph_lock        &amp;lt;---
  iterates to cf (tid=10)
  prepares FLUSH message
  drops i_ceph_lock        &amp;lt;---
  __send_cap() ── FLUSH(tid=10)
	                              MDS sends FLUSH_ACK(tid=10)
                           ---&amp;gt;       acquires i_ceph_lock
                                      cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),
                                      detaches cf from i_cap_flush_list
                                      drops i_ceph_lock
                                      ceph_free_cap_flush(cf) &amp;lt;- frees it!
  acquires i_ceph_lock     &amp;lt;---
  for-loop advances:
    cf = list_next_entry(cf, i_list)
      -- UAF on freed cf-&amp;gt;i_list.next&lt;/p&gt;
&lt;p&gt;The cf was just sent by __kick_flushing_caps itself via __send_cap().
The M…&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;ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock&lt;/p&gt;
&lt;p&gt;list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops
i_ceph_lock to send cap messages.  During the unlock window,
handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries
with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free
them via ceph_free_cap_flush() outside any lock.  When the original
thread reacquires i_ceph_lock and the for-loop macro advances via
cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next
on freed memory.&lt;/p&gt;
&lt;p&gt;The race timeline:&lt;/p&gt;
&lt;p&gt;__kick_flushing_caps()              handle_cap_flush_ack()
  -----------------------             -----------------------
  holds i_ceph_lock        &amp;lt;---
  iterates to cf (tid=10)
  prepares FLUSH message
  drops i_ceph_lock        &amp;lt;---
  __send_cap() ── FLUSH(tid=10)
	                              MDS sends FLUSH_ACK(tid=10)
                           ---&amp;gt;       acquires i_ceph_lock
                                      cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),
                                      detaches cf from i_cap_flush_list
                                      drops i_ceph_lock
                                      ceph_free_cap_flush(cf) &amp;lt;- frees it!
  acquires i_ceph_lock     &amp;lt;---
  for-loop advances:
    cf = list_next_entry(cf, i_list)
      -- UAF on freed cf-&amp;gt;i_list.next&lt;/p&gt;
&lt;p&gt;The cf was just sent by __kick_flushing_caps itself via __send_cap().
The M…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-67r3-hj2c-67vv</guid>
    </item>
    <item>
      <title>OESA-2026-4039 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-4039</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:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting.  OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long.  It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed().  This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.(CVE-2024-56531)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says: In the xsk_map_delete_elem function an unsigned integer(map-&amp;amp;gt;max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap-&amp;amp;gt;max_entries can bypass the intended bounds check: if (k &amp;amp;gt;= map-&amp;amp;gt;max_entries)  return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m-&amp;amp;gt;xsk_map[k], which resultsin an out-of-bounds access. spi…&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:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting.  OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long.  It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed().  This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.(CVE-2024-56531)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says: In the xsk_map_delete_elem function an unsigned integer(map-&amp;amp;gt;max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap-&amp;amp;gt;max_entries can bypass the intended bounds check: if (k &amp;amp;gt;= map-&amp;amp;gt;max_entries)  return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m-&amp;amp;gt;xsk_map[k], which resultsin an out-of-bounds access. spi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-4039</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-89655</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-89655</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: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops i_ceph_lock to send cap messages.  During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock.  When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next on freed memory. The race timeline:   __kick_flushing_caps()              handle_cap_flush_ack()   -----------------------             -----------------------   holds i_ceph_lock        &amp;lt;---   iterates to cf (tid=10)   prepares FLUSH message   drops i_ceph_lock        &amp;lt;---   __send_cap() ── FLUSH(tid=10) 	                              MDS sends FLUSH_ACK(tid=10)                            ---&amp;gt;       acquires i_ceph_lock                                       cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),                                       detaches cf from i_cap_flush_list                                       drops i_ceph_lock                                       ceph_free_cap_flush(cf) &amp;lt;- frees it!   acquires i_ceph_lock     &amp;lt;---   for-loop advances:     cf = list_next_entry(cf, i_list)       -- UAF on freed cf-&amp;gt;i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS ma…&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: ceph: fix UAF in __kick_flushing_caps() on cf entry freed during unlock list_for_each_entry() iterates ci-&amp;gt;i_cap_flush_list but drops i_ceph_lock to send cap messages.  During the unlock window, handle_cap_flush_ack() can acquire i_ceph_lock, detach cf entries with tid &amp;lt;= flush_tid from the list, release i_ceph_lock, and free them via ceph_free_cap_flush() outside any lock.  When the original thread reacquires i_ceph_lock and the for-loop macro advances via cf = list_next_entry(cf, i_list), it dereferences cf-&amp;gt;i_list.next on freed memory. The race timeline:   __kick_flushing_caps()              handle_cap_flush_ack()   -----------------------             -----------------------   holds i_ceph_lock        &amp;lt;---   iterates to cf (tid=10)   prepares FLUSH message   drops i_ceph_lock        &amp;lt;---   __send_cap() ── FLUSH(tid=10) 	                              MDS sends FLUSH_ACK(tid=10)                            ---&amp;gt;       acquires i_ceph_lock                                       cf-&amp;gt;tid(10) &amp;lt;= flush_tid(10),                                       detaches cf from i_cap_flush_list                                       drops i_ceph_lock                                       ceph_free_cap_flush(cf) &amp;lt;- frees it!   acquires i_ceph_lock     &amp;lt;---   for-loop advances:     cf = list_next_entry(cf, i_list)       -- UAF on freed cf-&amp;gt;i_list.next The cf was just sent by __kick_flushing_caps itself via __send_cap(). The MDS ma…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-89655</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3321 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsmaßnahmen zu umgehen, Daten oder den Systemzustand zu manipulieren, Denial-of-Service-Zustände herbeizuführen oder andere, nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3321</guid>
    </item>
  </channel>
</rss>
