<?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 15:36:16 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-12644</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-12644</link>
      <description>bdu:2026-12644</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-12644</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-31689</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31689</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-31689</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0526 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</link>
      <description>certfr-2026-avi-0526</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0526</guid>
    </item>
    <item>
      <title>EUVD-2026-315658</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315658</link>
      <description>EUVD-2026-315658</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315658</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31689</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31689</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;EDAC/mc: Fix error path ordering in edac_mc_alloc()&lt;/p&gt;
&lt;p&gt;When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path
will call put_device() which will end up calling the device&amp;#39;s release
function.&lt;/p&gt;
&lt;p&gt;However, the init ordering is wrong such that device_initialize() happens
*after* the failed allocation and thus the device itself and the release
function pointer are not initialized yet when they&amp;#39;re called:&lt;/p&gt;
&lt;p&gt;MCE: In-kernel MCE decoding enabled.
  ------------[ cut here ]------------
  kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.
  WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
  CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
  RIP: 0010:kobject_put
  Call Trace:
   &amp;lt;TASK&amp;gt;
   edac_mc_alloc+0xbe/0xe0 [edac_core]
   amd64_edac_init+0x7a4/0xff0 [amd64_edac]
   ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
   do_one_initcall
   ...&lt;/p&gt;
&lt;p&gt;Reorder the calling sequence so that the device is initialized and thus the
release function pointer is properly set before it can be used.&lt;/p&gt;
&lt;p&gt;This was found by Claude while reviewing another EDAC patch.&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;EDAC/mc: Fix error path ordering in edac_mc_alloc()&lt;/p&gt;
&lt;p&gt;When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path
will call put_device() which will end up calling the device&amp;#39;s release
function.&lt;/p&gt;
&lt;p&gt;However, the init ordering is wrong such that device_initialize() happens
*after* the failed allocation and thus the device itself and the release
function pointer are not initialized yet when they&amp;#39;re called:&lt;/p&gt;
&lt;p&gt;MCE: In-kernel MCE decoding enabled.
  ------------[ cut here ]------------
  kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.
  WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
  CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
  RIP: 0010:kobject_put
  Call Trace:
   &amp;lt;TASK&amp;gt;
   edac_mc_alloc+0xbe/0xe0 [edac_core]
   amd64_edac_init+0x7a4/0xff0 [amd64_edac]
   ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
   do_one_initcall
   ...&lt;/p&gt;
&lt;p&gt;Reorder the calling sequence so that the device is initialized and thus the
release function pointer is properly set before it can be used.&lt;/p&gt;
&lt;p&gt;This was found by Claude while reviewing another EDAC patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31689</guid>
    </item>
    <item>
      <title>GHSA-9qrw-cmg5-g8vq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-9qrw-cmg5-g8vq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;EDAC/mc: Fix error path ordering in edac_mc_alloc()&lt;/p&gt;
&lt;p&gt;When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path
will call put_device() which will end up calling the device&amp;#39;s release
function.&lt;/p&gt;
&lt;p&gt;However, the init ordering is wrong such that device_initialize() happens
*after* the failed allocation and thus the device itself and the release
function pointer are not initialized yet when they&amp;#39;re called:&lt;/p&gt;
&lt;p&gt;MCE: In-kernel MCE decoding enabled.
  ------------[ cut here ]------------
  kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.
  WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
  CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
  RIP: 0010:kobject_put
  Call Trace:
   &amp;lt;TASK&amp;gt;
   edac_mc_alloc+0xbe/0xe0 [edac_core]
   amd64_edac_init+0x7a4/0xff0 [amd64_edac]
   ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
   do_one_initcall
   ...&lt;/p&gt;
&lt;p&gt;Reorder the calling sequence so that the device is initialized and thus the
release function pointer is properly set before it can be used.&lt;/p&gt;
&lt;p&gt;This was found by Claude while reviewing another EDAC patch.&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;EDAC/mc: Fix error path ordering in edac_mc_alloc()&lt;/p&gt;
&lt;p&gt;When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path
will call put_device() which will end up calling the device&amp;#39;s release
function.&lt;/p&gt;
&lt;p&gt;However, the init ordering is wrong such that device_initialize() happens
*after* the failed allocation and thus the device itself and the release
function pointer are not initialized yet when they&amp;#39;re called:&lt;/p&gt;
&lt;p&gt;MCE: In-kernel MCE decoding enabled.
  ------------[ cut here ]------------
  kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.
  WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd
  CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)
  RIP: 0010:kobject_put
  Call Trace:
   &amp;lt;TASK&amp;gt;
   edac_mc_alloc+0xbe/0xe0 [edac_core]
   amd64_edac_init+0x7a4/0xff0 [amd64_edac]
   ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]
   do_one_initcall
   ...&lt;/p&gt;
&lt;p&gt;Reorder the calling sequence so that the device is initialized and thus the
release function pointer is properly set before it can be used.&lt;/p&gt;
&lt;p&gt;This was found by Claude while reviewing another EDAC patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-9qrw-cmg5-g8vq</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-31689 — EDAC/mc: Fix error path ordering in edac_mc_alloc()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31689</link>
      <description>msrc_CVE-2026-31689</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-31689</guid>
    </item>
    <item>
      <title>OESA-2026-2581 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2581</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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:&lt;/p&gt;
&lt;p&gt;net: mvpp2: Prevent parser TCAM memory corruption&lt;/p&gt;
&lt;p&gt;Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.&lt;/p&gt;
&lt;p&gt;Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.&lt;/p&gt;
&lt;p&gt;This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.(CVE-2025-22060)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mptcp: fix NULL pointer in can_accept_new_subflow&lt;/p&gt;
&lt;p&gt;When testing valkey benchmark tool with MPTCP, the kernel panics in
&amp;amp;apos;mptcp_can_accept_new_subflow&amp;amp;apos; because subflow_req-&amp;amp;gt;msk is NULL.&lt;/p&gt;
&lt;p&gt;Call trace:&lt;/p&gt;
&lt;p&gt;mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
  subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
  tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
  tcp_v4_rcv (./net/…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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:&lt;/p&gt;
&lt;p&gt;net: mvpp2: Prevent parser TCAM memory corruption&lt;/p&gt;
&lt;p&gt;Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM
information, from concurrent modifications.&lt;/p&gt;
&lt;p&gt;Both the TCAM and SRAM tables are indirectly accessed by configuring
an index register that selects the row to read or write to. This means
that operations must be atomic in order to, e.g., avoid spreading
writes across multiple rows. Since the shadow SRAM array is used to
find free rows in the hardware table, it must also be protected in
order to avoid TOCTOU errors where multiple cores allocate the same
row.&lt;/p&gt;
&lt;p&gt;This issue was detected in a situation where `mvpp2_set_rx_mode()` ran
concurrently on two CPUs. In this particular case the
MVPP2_PE_MAC_UC_PROMISCUOUS entry was corrupted, causing the
classifier unit to drop all incoming unicast - indicated by the
`rx_classifier_drops` counter.(CVE-2025-22060)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mptcp: fix NULL pointer in can_accept_new_subflow&lt;/p&gt;
&lt;p&gt;When testing valkey benchmark tool with MPTCP, the kernel panics in
&amp;amp;apos;mptcp_can_accept_new_subflow&amp;amp;apos; because subflow_req-&amp;amp;gt;msk is NULL.&lt;/p&gt;
&lt;p&gt;Call trace:&lt;/p&gt;
&lt;p&gt;mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)
  subflow_syn_recv_sock (./net/mptcp/subflow.c:854)
  tcp_check_req (./net/ipv4/tcp_minisocks.c:863)
  tcp_v4_rcv (./net/…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2581</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31689</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31689</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 141 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: EDAC/mc: Fix error path ordering in edac_mc_alloc() When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device&amp;#39;s release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they&amp;#39;re called:   MCE: In-kernel MCE decoding enabled.   ------------[ cut here ]------------   kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.   WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd   CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)   RIP: 0010:kobject_put   Call Trace:    &amp;lt;TASK&amp;gt;    edac_mc_alloc+0xbe/0xe0 [edac_core]    amd64_edac_init+0x7a4/0xff0 [amd64_edac]    ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]    do_one_initcall    ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch.&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 141 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: EDAC/mc: Fix error path ordering in edac_mc_alloc() When the mci-&amp;gt;pvt_info allocation in edac_mc_alloc() fails, the error path will call put_device() which will end up calling the device&amp;#39;s release function. However, the init ordering is wrong such that device_initialize() happens *after* the failed allocation and thus the device itself and the release function pointer are not initialized yet when they&amp;#39;re called:   MCE: In-kernel MCE decoding enabled.   ------------[ cut here ]------------   kobject: &amp;#39;(null)&amp;#39;: is not initialized, yet kobject_put() is being called.   WARNING: lib/kobject.c:734 at kobject_put, CPU#22: systemd-udevd   CPU: 22 UID: 0 PID: 538 Comm: systemd-udevd Not tainted 7.0.0-rc1+ #2 PREEMPT(full)   RIP: 0010:kobject_put   Call Trace:    &amp;lt;TASK&amp;gt;    edac_mc_alloc+0xbe/0xe0 [edac_core]    amd64_edac_init+0x7a4/0xff0 [amd64_edac]    ? __pfx_amd64_edac_init+0x10/0x10 [amd64_edac]    do_one_initcall    ... Reorder the calling sequence so that the device is initialized and thus the release function pointer is properly set before it can be used. This was found by Claude while reviewing another EDAC patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31689</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1294 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1294</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierte Angriffe durchzuführen, die einen Denial-of-Service-Zustand, die Ausführung von Code oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierte Angriffe durchzuführen, die einen Denial-of-Service-Zustand, die Ausführung von Code oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1294</guid>
    </item>
  </channel>
</rss>
