<?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 17:51:59 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-07517</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-07517</link>
      <description>bdu:2026-07517</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-07517</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-71130</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-71130</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-2025-71130</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</link>
      <description>certfr-2026-avi-0166</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</guid>
    </item>
    <item>
      <title>EUVD-2026-347553</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347553</link>
      <description>EUVD-2026-347553</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347553</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71130</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71130</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer&lt;/p&gt;
&lt;p&gt;Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.&lt;/p&gt;
&lt;p&gt;During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer.&lt;/p&gt;
&lt;p&gt;If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know
at what point did the lookup function fail.&lt;/p&gt;
&lt;p&gt;In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.&lt;/p&gt;
&lt;p&gt;When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison v…&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;drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer&lt;/p&gt;
&lt;p&gt;Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.&lt;/p&gt;
&lt;p&gt;During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer.&lt;/p&gt;
&lt;p&gt;If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know
at what point did the lookup function fail.&lt;/p&gt;
&lt;p&gt;In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.&lt;/p&gt;
&lt;p&gt;When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71130</guid>
    </item>
    <item>
      <title>GHSA-fcj7-h6w4-whvj</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fcj7-h6w4-whvj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer&lt;/p&gt;
&lt;p&gt;Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.&lt;/p&gt;
&lt;p&gt;During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer.&lt;/p&gt;
&lt;p&gt;If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know
at what point did the lookup function fail.&lt;/p&gt;
&lt;p&gt;In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.&lt;/p&gt;
&lt;p&gt;When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison v…&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;drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer&lt;/p&gt;
&lt;p&gt;Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.&lt;/p&gt;
&lt;p&gt;During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer.&lt;/p&gt;
&lt;p&gt;If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know
at what point did the lookup function fail.&lt;/p&gt;
&lt;p&gt;In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.&lt;/p&gt;
&lt;p&gt;When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fcj7-h6w4-whvj</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-71130 — drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-71130</link>
      <description>msrc_CVE-2025-71130</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-71130</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>openSUSE-SU-2026:20287-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-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:20287-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0587-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0587-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:0587-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-71130</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71130</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: drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below. During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value,…&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: drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer Initialize the eb.vma array with values of 0 when the eb structure is first set up. In particular, this sets the eb-&amp;gt;vma[i].vma pointers to NULL, simplifying cleanup and getting rid of the bug described below. During the execution of eb_lookup_vmas(), the eb-&amp;gt;vma array is successively filled up with struct eb_vma objects. This process includes calling eb_add_vma(), which might fail; however, even in the event of failure, eb-&amp;gt;vma[i].vma is set for the currently processed buffer. If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which prompts a call to eb_release_vmas() to clean up the mess. Since eb_lookup_vmas() might fail during processing any (possibly not first) buffer, eb_release_vmas() checks whether a buffer&amp;#39;s vma is NULL to know at what point did the lookup function fail. In eb_lookup_vmas(), eb-&amp;gt;vma[i].vma is set to NULL if either the helper function eb_lookup_vma() or eb_validate_vma() fails. eb-&amp;gt;vma[i+1].vma is set to NULL in case i915_gem_object_userptr_submit_init() fails; the current one needs to be cleaned up by eb_release_vmas() at this point, so the next one is set. If eb_add_vma() fails, neither the current nor the next vma is set to NULL, which is a source of a NULL deref bug described in the issue linked in the Closes tag. When entering eb_lookup_vmas(), the vma pointers are set to the slab poison value,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71130</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0119 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0119</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen 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 nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0119</guid>
    </item>
  </channel>
</rss>
