<?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 16:16:52 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12758</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12758</link>
      <description>bdu:2026-12758</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12758</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-43455</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43455</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-43455</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0782 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0782</link>
      <description>certfr-2026-avi-0782</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0782</guid>
    </item>
    <item>
      <title>EUVD-2026-315956</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315956</link>
      <description>EUVD-2026-315956</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315956</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43455</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43455</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output()&lt;/p&gt;
&lt;p&gt;mctp_flow_prepare_output() checks key-&amp;gt;dev and may call
mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so.&lt;/p&gt;
&lt;p&gt;mctp_dev_set_key() and mctp_dev_release_key() are annotated with
__must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be
serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches
mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output()
without holding key-&amp;gt;lock, so the check-and-set sequence is racy.&lt;/p&gt;
&lt;p&gt;Example interleaving:&lt;/p&gt;
&lt;p&gt;CPU0                                  CPU1
  ----                                  ----
  mctp_flow_prepare_output(key, devA)
    if (!key-&amp;gt;dev)  // sees NULL
                                        mctp_flow_prepare_output(
                                            key, devB)
                                          if (!key-&amp;gt;dev)  // still NULL
                                          mctp_dev_set_key(devB, key)
                                            mctp_dev_hold(devB)
                                            key-&amp;gt;dev = devB
    mctp_dev_set_key(devA, key)
      mctp_dev_hold(devA)
      key-&amp;gt;dev = devA   // overwrites devB&lt;/p&gt;
&lt;p&gt;Now both devA and devB references were acquired, but only the final
key-&amp;gt;dev value is tracked for release. One reference can be lost,
causing a resource leak as mctp_dev_release_key() would only decrease
the reference on one dev.&lt;/p&gt;
&lt;p&gt;Fix by taki…&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;mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output()&lt;/p&gt;
&lt;p&gt;mctp_flow_prepare_output() checks key-&amp;gt;dev and may call
mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so.&lt;/p&gt;
&lt;p&gt;mctp_dev_set_key() and mctp_dev_release_key() are annotated with
__must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be
serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches
mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output()
without holding key-&amp;gt;lock, so the check-and-set sequence is racy.&lt;/p&gt;
&lt;p&gt;Example interleaving:&lt;/p&gt;
&lt;p&gt;CPU0                                  CPU1
  ----                                  ----
  mctp_flow_prepare_output(key, devA)
    if (!key-&amp;gt;dev)  // sees NULL
                                        mctp_flow_prepare_output(
                                            key, devB)
                                          if (!key-&amp;gt;dev)  // still NULL
                                          mctp_dev_set_key(devB, key)
                                            mctp_dev_hold(devB)
                                            key-&amp;gt;dev = devB
    mctp_dev_set_key(devA, key)
      mctp_dev_hold(devA)
      key-&amp;gt;dev = devA   // overwrites devB&lt;/p&gt;
&lt;p&gt;Now both devA and devB references were acquired, but only the final
key-&amp;gt;dev value is tracked for release. One reference can be lost,
causing a resource leak as mctp_dev_release_key() would only decrease
the reference on one dev.&lt;/p&gt;
&lt;p&gt;Fix by taki…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43455</guid>
    </item>
    <item>
      <title>GHSA-qq8v-696h-fhv2</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-qq8v-696h-fhv2</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output()&lt;/p&gt;
&lt;p&gt;mctp_flow_prepare_output() checks key-&amp;gt;dev and may call
mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so.&lt;/p&gt;
&lt;p&gt;mctp_dev_set_key() and mctp_dev_release_key() are annotated with
__must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be
serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches
mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output()
without holding key-&amp;gt;lock, so the check-and-set sequence is racy.&lt;/p&gt;
&lt;p&gt;Example interleaving:&lt;/p&gt;
&lt;p&gt;CPU0                                  CPU1
  ----                                  ----
  mctp_flow_prepare_output(key, devA)
    if (!key-&amp;gt;dev)  // sees NULL
                                        mctp_flow_prepare_output(
                                            key, devB)
                                          if (!key-&amp;gt;dev)  // still NULL
                                          mctp_dev_set_key(devB, key)
                                            mctp_dev_hold(devB)
                                            key-&amp;gt;dev = devB
    mctp_dev_set_key(devA, key)
      mctp_dev_hold(devA)
      key-&amp;gt;dev = devA   // overwrites devB&lt;/p&gt;
&lt;p&gt;Now both devA and devB references were acquired, but only the final
key-&amp;gt;dev value is tracked for release. One reference can be lost,
causing a resource leak as mctp_dev_release_key() would only decrease
the reference on one dev.&lt;/p&gt;
&lt;p&gt;Fix by taki…&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;mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output()&lt;/p&gt;
&lt;p&gt;mctp_flow_prepare_output() checks key-&amp;gt;dev and may call
mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so.&lt;/p&gt;
&lt;p&gt;mctp_dev_set_key() and mctp_dev_release_key() are annotated with
__must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be
serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches
mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output()
without holding key-&amp;gt;lock, so the check-and-set sequence is racy.&lt;/p&gt;
&lt;p&gt;Example interleaving:&lt;/p&gt;
&lt;p&gt;CPU0                                  CPU1
  ----                                  ----
  mctp_flow_prepare_output(key, devA)
    if (!key-&amp;gt;dev)  // sees NULL
                                        mctp_flow_prepare_output(
                                            key, devB)
                                          if (!key-&amp;gt;dev)  // still NULL
                                          mctp_dev_set_key(devB, key)
                                            mctp_dev_hold(devB)
                                            key-&amp;gt;dev = devB
    mctp_dev_set_key(devA, key)
      mctp_dev_hold(devA)
      key-&amp;gt;dev = devA   // overwrites devB&lt;/p&gt;
&lt;p&gt;Now both devA and devB references were acquired, but only the final
key-&amp;gt;dev value is tracked for release. One reference can be lost,
causing a resource leak as mctp_dev_release_key() would only decrease
the reference on one dev.&lt;/p&gt;
&lt;p&gt;Fix by taki…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-qq8v-696h-fhv2</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20965-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20965-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:20965-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:22099-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:22099-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:22099-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43455</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43455</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: mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output() mctp_flow_prepare_output() checks key-&amp;gt;dev and may call mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so. mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output() without holding key-&amp;gt;lock, so the check-and-set sequence is racy. Example interleaving:   CPU0                                  CPU1   ----                                  ----   mctp_flow_prepare_output(key, devA)     if (!key-&amp;gt;dev)  // sees NULL                                         mctp_flow_prepare_output(                                             key, devB)                                           if (!key-&amp;gt;dev)  // still NULL                                           mctp_dev_set_key(devB, key)                                             mctp_dev_hold(devB)                                             key-&amp;gt;dev = devB     mctp_dev_set_key(devA, key)       mctp_dev_hold(devA)       key-&amp;gt;dev = devA   // overwrites devB Now both devA and devB references were acquired, but only the final key-&amp;gt;dev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev. Fix by taking key-…&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: mctp: route: hold key-&amp;gt;lock in mctp_flow_prepare_output() mctp_flow_prepare_output() checks key-&amp;gt;dev and may call mctp_dev_set_key(), but it does not hold key-&amp;gt;lock while doing so. mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(&amp;amp;key-&amp;gt;lock), so key-&amp;gt;dev access is intended to be serialized by key-&amp;gt;lock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -&amp;gt; mctp_dst_output() without holding key-&amp;gt;lock, so the check-and-set sequence is racy. Example interleaving:   CPU0                                  CPU1   ----                                  ----   mctp_flow_prepare_output(key, devA)     if (!key-&amp;gt;dev)  // sees NULL                                         mctp_flow_prepare_output(                                             key, devB)                                           if (!key-&amp;gt;dev)  // still NULL                                           mctp_dev_set_key(devB, key)                                             mctp_dev_hold(devB)                                             key-&amp;gt;dev = devB     mctp_dev_set_key(devA, key)       mctp_dev_hold(devA)       key-&amp;gt;dev = devA   // overwrites devB Now both devA and devB references were acquired, but only the final key-&amp;gt;dev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev. Fix by taking key-…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43455</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1454 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1454</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, 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 einen nicht näher spezifizierten Angriff 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-1454</guid>
    </item>
  </channel>
</rss>
