<?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 21:56:11 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12462</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12462</link>
      <description>bdu:2026-12462</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12462</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-23322</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23322</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-23322</guid>
    </item>
    <item>
      <title>EUVD-2026-315470</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315470</link>
      <description>EUVD-2026-315470</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315470</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23322</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23322</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipmi: Fix use-after-free and list corruption on sender error&lt;/p&gt;
&lt;p&gt;The analysis from Breno:&lt;/p&gt;
&lt;p&gt;When the SMI sender returns an error, smi_work() delivers an error
response but then jumps back to restart without cleaning up properly:&lt;/p&gt;
&lt;p&gt;1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled
2. newmsg still points to the message, causing sender() to be called
   again with the same message
3. If sender() fails again, deliver_err_response() is called with
   the same recv_msg that was already queued for delivery&lt;/p&gt;
&lt;p&gt;This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the
recv_msg is added to the user_msgs list twice. Subsequently, the
corrupted list leads to use-after-free when the memory is freed and
reused, and eventually a NULL pointer dereference when accessing
recv_msg-&amp;gt;done.&lt;/p&gt;
&lt;p&gt;The buggy sequence:&lt;/p&gt;
&lt;p&gt;sender() fails
    -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery
    -&amp;gt; goto restart                    // curr_msg not cleared!
  sender() fails again (same message!)
    -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg
    -&amp;gt; LIST CORRUPTION&lt;/p&gt;
&lt;p&gt;Fix this by freeing the message and setting it to NULL on a send error.
Also, always free the newmsg on a send error, otherwise it will leak.&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;ipmi: Fix use-after-free and list corruption on sender error&lt;/p&gt;
&lt;p&gt;The analysis from Breno:&lt;/p&gt;
&lt;p&gt;When the SMI sender returns an error, smi_work() delivers an error
response but then jumps back to restart without cleaning up properly:&lt;/p&gt;
&lt;p&gt;1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled
2. newmsg still points to the message, causing sender() to be called
   again with the same message
3. If sender() fails again, deliver_err_response() is called with
   the same recv_msg that was already queued for delivery&lt;/p&gt;
&lt;p&gt;This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the
recv_msg is added to the user_msgs list twice. Subsequently, the
corrupted list leads to use-after-free when the memory is freed and
reused, and eventually a NULL pointer dereference when accessing
recv_msg-&amp;gt;done.&lt;/p&gt;
&lt;p&gt;The buggy sequence:&lt;/p&gt;
&lt;p&gt;sender() fails
    -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery
    -&amp;gt; goto restart                    // curr_msg not cleared!
  sender() fails again (same message!)
    -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg
    -&amp;gt; LIST CORRUPTION&lt;/p&gt;
&lt;p&gt;Fix this by freeing the message and setting it to NULL on a send error.
Also, always free the newmsg on a send error, otherwise it will leak.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-23322</guid>
    </item>
    <item>
      <title>GHSA-668m-q5h4-jfjc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-668m-q5h4-jfjc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipmi: Fix use-after-free and list corruption on sender error&lt;/p&gt;
&lt;p&gt;The analysis from Breno:&lt;/p&gt;
&lt;p&gt;When the SMI sender returns an error, smi_work() delivers an error
response but then jumps back to restart without cleaning up properly:&lt;/p&gt;
&lt;p&gt;1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled
2. newmsg still points to the message, causing sender() to be called
   again with the same message
3. If sender() fails again, deliver_err_response() is called with
   the same recv_msg that was already queued for delivery&lt;/p&gt;
&lt;p&gt;This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the
recv_msg is added to the user_msgs list twice. Subsequently, the
corrupted list leads to use-after-free when the memory is freed and
reused, and eventually a NULL pointer dereference when accessing
recv_msg-&amp;gt;done.&lt;/p&gt;
&lt;p&gt;The buggy sequence:&lt;/p&gt;
&lt;p&gt;sender() fails
    -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery
    -&amp;gt; goto restart                    // curr_msg not cleared!
  sender() fails again (same message!)
    -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg
    -&amp;gt; LIST CORRUPTION&lt;/p&gt;
&lt;p&gt;Fix this by freeing the message and setting it to NULL on a send error.
Also, always free the newmsg on a send error, otherwise it will leak.&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;ipmi: Fix use-after-free and list corruption on sender error&lt;/p&gt;
&lt;p&gt;The analysis from Breno:&lt;/p&gt;
&lt;p&gt;When the SMI sender returns an error, smi_work() delivers an error
response but then jumps back to restart without cleaning up properly:&lt;/p&gt;
&lt;p&gt;1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled
2. newmsg still points to the message, causing sender() to be called
   again with the same message
3. If sender() fails again, deliver_err_response() is called with
   the same recv_msg that was already queued for delivery&lt;/p&gt;
&lt;p&gt;This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the
recv_msg is added to the user_msgs list twice. Subsequently, the
corrupted list leads to use-after-free when the memory is freed and
reused, and eventually a NULL pointer dereference when accessing
recv_msg-&amp;gt;done.&lt;/p&gt;
&lt;p&gt;The buggy sequence:&lt;/p&gt;
&lt;p&gt;sender() fails
    -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery
    -&amp;gt; goto restart                    // curr_msg not cleared!
  sender() fails again (same message!)
    -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg
    -&amp;gt; LIST CORRUPTION&lt;/p&gt;
&lt;p&gt;Fix this by freeing the message and setting it to NULL on a send error.
Also, always free the newmsg on a send error, otherwise it will leak.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-668m-q5h4-jfjc</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-23322</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23322</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 82 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix use-after-free and list corruption on sender error The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called    again with the same message 3. If sender() fails again, deliver_err_response() is called with    the same recv_msg that was already queued for delivery This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg-&amp;gt;done. The buggy sequence:   sender() fails     -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery     -&amp;gt; goto restart                    // curr_msg not cleared!   sender() fails again (same message!)     -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg     -&amp;gt; LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak.&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 82 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix use-after-free and list corruption on sender error The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf-&amp;gt;curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called    again with the same message 3. If sender() fails again, deliver_err_response() is called with    the same recv_msg that was already queued for delivery This causes list_add corruption (&amp;#34;list_add double add&amp;#34;) because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg-&amp;gt;done. The buggy sequence:   sender() fails     -&amp;gt; deliver_err_response(recv_msg)  // recv_msg queued for delivery     -&amp;gt; goto restart                    // curr_msg not cleared!   sender() fails again (same message!)     -&amp;gt; deliver_err_response(recv_msg)  // tries to queue same recv_msg     -&amp;gt; LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23322</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0861 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861</guid>
    </item>
  </channel>
</rss>
