<?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>Tue, 06 Oct 2026 10:03:40 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-63989</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-63989</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-63989</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0926 — 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-0926</link>
      <description>certfr-2026-avi-0926</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</guid>
    </item>
    <item>
      <title>EUVD-2026-338715</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-338715</link>
      <description>EUVD-2026-338715</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-338715</guid>
    </item>
    <item>
      <title>fkie_cve-2026-63989</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-63989</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bridge: Fix sleep in atomic context in netlink path&lt;/p&gt;
&lt;p&gt;Since the introduction of the netlink configuration path for bridge
ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over
netlink&amp;#34;), br_setport() was always called with the bridge lock held
around it. Back then this decision made sense: The bridge lock protects
the STP state of the bridge and its ports and at that time the function
only processed three STP related netlink attributes (cost, priority and
state).&lt;/p&gt;
&lt;p&gt;Nowadays, br_setport() processes a lot more attributes and most of them
do not need the bridge lock:&lt;/p&gt;
&lt;p&gt;* Bridge flags: Only require RTNL. Read locklessly by the data path.
  Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* FDB port flushing: Only requires the FDB lock.&lt;/p&gt;
&lt;p&gt;* Multicast attributes: Only require the multicast lock.&lt;/p&gt;
&lt;p&gt;* Group forward mask: Only requires RTNL. Read locklessly by the data
  path. Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* Backup port and NHID: Only require RTNL. Read locklessly by the data
  path.&lt;/p&gt;
&lt;p&gt;This is a problem as the bridge calls dev_set_promiscuity() when certain
bridge port flags change and this function can sleep since the commit
cited below, resulting in a splat such as [1].&lt;/p&gt;
&lt;p&gt;Fix this by reducing the scope of the bridge lock and only take it when
processing the three STP related attributes that require it. This is
consistent with the multicast attributes where each attribute acquires
the multicast lock instead of…&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;bridge: Fix sleep in atomic context in netlink path&lt;/p&gt;
&lt;p&gt;Since the introduction of the netlink configuration path for bridge
ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over
netlink&amp;#34;), br_setport() was always called with the bridge lock held
around it. Back then this decision made sense: The bridge lock protects
the STP state of the bridge and its ports and at that time the function
only processed three STP related netlink attributes (cost, priority and
state).&lt;/p&gt;
&lt;p&gt;Nowadays, br_setport() processes a lot more attributes and most of them
do not need the bridge lock:&lt;/p&gt;
&lt;p&gt;* Bridge flags: Only require RTNL. Read locklessly by the data path.
  Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* FDB port flushing: Only requires the FDB lock.&lt;/p&gt;
&lt;p&gt;* Multicast attributes: Only require the multicast lock.&lt;/p&gt;
&lt;p&gt;* Group forward mask: Only requires RTNL. Read locklessly by the data
  path. Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* Backup port and NHID: Only require RTNL. Read locklessly by the data
  path.&lt;/p&gt;
&lt;p&gt;This is a problem as the bridge calls dev_set_promiscuity() when certain
bridge port flags change and this function can sleep since the commit
cited below, resulting in a splat such as [1].&lt;/p&gt;
&lt;p&gt;Fix this by reducing the scope of the bridge lock and only take it when
processing the three STP related attributes that require it. This is
consistent with the multicast attributes where each attribute acquires
the multicast lock instead of…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-63989</guid>
    </item>
    <item>
      <title>GHSA-5x9q-485p-2v5m</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5x9q-485p-2v5m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bridge: Fix sleep in atomic context in netlink path&lt;/p&gt;
&lt;p&gt;Since the introduction of the netlink configuration path for bridge
ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over
netlink&amp;#34;), br_setport() was always called with the bridge lock held
around it. Back then this decision made sense: The bridge lock protects
the STP state of the bridge and its ports and at that time the function
only processed three STP related netlink attributes (cost, priority and
state).&lt;/p&gt;
&lt;p&gt;Nowadays, br_setport() processes a lot more attributes and most of them
do not need the bridge lock:&lt;/p&gt;
&lt;p&gt;* Bridge flags: Only require RTNL. Read locklessly by the data path.
  Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* FDB port flushing: Only requires the FDB lock.&lt;/p&gt;
&lt;p&gt;* Multicast attributes: Only require the multicast lock.&lt;/p&gt;
&lt;p&gt;* Group forward mask: Only requires RTNL. Read locklessly by the data
  path. Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* Backup port and NHID: Only require RTNL. Read locklessly by the data
  path.&lt;/p&gt;
&lt;p&gt;This is a problem as the bridge calls dev_set_promiscuity() when certain
bridge port flags change and this function can sleep since the commit
cited below, resulting in a splat such as [1].&lt;/p&gt;
&lt;p&gt;Fix this by reducing the scope of the bridge lock and only take it when
processing the three STP related attributes that require it. This is
consistent with the multicast attributes where each attribute acquires
the multicast lock instead of…&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;bridge: Fix sleep in atomic context in netlink path&lt;/p&gt;
&lt;p&gt;Since the introduction of the netlink configuration path for bridge
ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over
netlink&amp;#34;), br_setport() was always called with the bridge lock held
around it. Back then this decision made sense: The bridge lock protects
the STP state of the bridge and its ports and at that time the function
only processed three STP related netlink attributes (cost, priority and
state).&lt;/p&gt;
&lt;p&gt;Nowadays, br_setport() processes a lot more attributes and most of them
do not need the bridge lock:&lt;/p&gt;
&lt;p&gt;* Bridge flags: Only require RTNL. Read locklessly by the data path.
  Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* FDB port flushing: Only requires the FDB lock.&lt;/p&gt;
&lt;p&gt;* Multicast attributes: Only require the multicast lock.&lt;/p&gt;
&lt;p&gt;* Group forward mask: Only requires RTNL. Read locklessly by the data
  path. Annotations can be added in net-next.&lt;/p&gt;
&lt;p&gt;* Backup port and NHID: Only require RTNL. Read locklessly by the data
  path.&lt;/p&gt;
&lt;p&gt;This is a problem as the bridge calls dev_set_promiscuity() when certain
bridge port flags change and this function can sleep since the commit
cited below, resulting in a splat such as [1].&lt;/p&gt;
&lt;p&gt;Fix this by reducing the scope of the bridge lock and only take it when
processing the three STP related attributes that require it. This is
consistent with the multicast attributes where each attribute acquires
the multicast lock instead of…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5x9q-485p-2v5m</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-63989</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-63989</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 118 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over netlink&amp;#34;), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path.   Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data   path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data   path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having on…&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 118 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bridge: Fix sleep in atomic context in netlink path Since the introduction of the netlink configuration path for bridge ports in commit 25c71c75ac87 (&amp;#34;bridge: bridge port parameters over netlink&amp;#34;), br_setport() was always called with the bridge lock held around it. Back then this decision made sense: The bridge lock protects the STP state of the bridge and its ports and at that time the function only processed three STP related netlink attributes (cost, priority and state). Nowadays, br_setport() processes a lot more attributes and most of them do not need the bridge lock: * Bridge flags: Only require RTNL. Read locklessly by the data path.   Annotations can be added in net-next. * FDB port flushing: Only requires the FDB lock. * Multicast attributes: Only require the multicast lock. * Group forward mask: Only requires RTNL. Read locklessly by the data   path. Annotations can be added in net-next. * Backup port and NHID: Only require RTNL. Read locklessly by the data   path. This is a problem as the bridge calls dev_set_promiscuity() when certain bridge port flags change and this function can sleep since the commit cited below, resulting in a splat such as [1]. Fix this by reducing the scope of the bridge lock and only take it when processing the three STP related attributes that require it. This is consistent with the multicast attributes where each attribute acquires the multicast lock instead of having on…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-63989</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2403 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&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, möglicherweise Sicherheitsmaßnahmen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2403</guid>
    </item>
  </channel>
</rss>
