<?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 17:31:30 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68405</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68405</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-68405</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1069 — 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-1069</link>
      <description>certfr-2026-avi-1069</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</guid>
    </item>
    <item>
      <title>EUVD-2026-356328</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356328</link>
      <description>EUVD-2026-356328</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356328</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68405</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68405</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock&lt;/p&gt;
&lt;p&gt;ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.&lt;/p&gt;
&lt;p&gt;ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;AP_VLAN management TX:             AP_VLAN stop:
1. attach ACK-status state         1. clear the running state
2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs
   parent ps-&amp;gt;bc_buf                  disabled
                                   3. unlink the AP_VLAN SKB
                                   4. call ieee80211_free_txskb()&lt;/p&gt;
&lt;p&gt;Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().&lt;/p&gt;
&lt;p&gt;WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&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;wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock&lt;/p&gt;
&lt;p&gt;ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.&lt;/p&gt;
&lt;p&gt;ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;AP_VLAN management TX:             AP_VLAN stop:
1. attach ACK-status state         1. clear the running state
2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs
   parent ps-&amp;gt;bc_buf                  disabled
                                   3. unlink the AP_VLAN SKB
                                   4. call ieee80211_free_txskb()&lt;/p&gt;
&lt;p&gt;Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().&lt;/p&gt;
&lt;p&gt;WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68405</guid>
    </item>
    <item>
      <title>GHSA-qx36-wgrc-gggh</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-qx36-wgrc-gggh</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock&lt;/p&gt;
&lt;p&gt;ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.&lt;/p&gt;
&lt;p&gt;ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;AP_VLAN management TX:             AP_VLAN stop:
1. attach ACK-status state         1. clear the running state
2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs
   parent ps-&amp;gt;bc_buf                  disabled
                                   3. unlink the AP_VLAN SKB
                                   4. call ieee80211_free_txskb()&lt;/p&gt;
&lt;p&gt;Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().&lt;/p&gt;
&lt;p&gt;WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&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;wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock&lt;/p&gt;
&lt;p&gt;ieee80211_do_stop() removes AP_VLAN packets from the parent AP
ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then
calls ieee80211_free_txskb() before dropping the lock.&lt;/p&gt;
&lt;p&gt;ieee80211_free_txskb() is not just a passive SKB release. For SKBs with
TX status state it can report a dropped frame through cfg80211/nl80211,
and that path can reach netlink tap transmit. This is the same reason
the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs
under the queue lock and frees them after IRQ state is restored.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the
order within that path:&lt;/p&gt;
&lt;p&gt;AP_VLAN management TX:             AP_VLAN stop:
1. attach ACK-status state         1. clear the running state
2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs
   parent ps-&amp;gt;bc_buf                  disabled
                                   3. unlink the AP_VLAN SKB
                                   4. call ieee80211_free_txskb()&lt;/p&gt;
&lt;p&gt;Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock,
but move them to a local free queue. Drop the lock and restore IRQ state
before calling ieee80211_free_txskb().&lt;/p&gt;
&lt;p&gt;WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-qx36-wgrc-gggh</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68405 — wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68405</link>
      <description>msrc_CVE-2026-68405</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68405</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-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:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-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:23477-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68405</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68405</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: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX:             AP_VLAN stop: 1. attach ACK-status state         1. clear the running state 2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs    parent ps-&amp;gt;bc_buf                  disabled                                    3. unlink the AP_VLAN SKB                                    4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&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: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps-&amp;gt;bc_buf while holding ps-&amp;gt;bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX:             AP_VLAN stop: 1. attach ACK-status state         1. clear the running state 2. queue a multicast SKB on        2. take ps-&amp;gt;bc_buf.lock with IRQs    parent ps-&amp;gt;bc_buf                  disabled                                    3. unlink the AP_VLAN SKB                                    4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps-&amp;gt;bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68405</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</guid>
    </item>
  </channel>
</rss>
