<?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 14:16:20 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2025-71160</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-71160</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-71160</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-315227</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-315227</link>
      <description>EUVD-2026-315227</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-315227</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71160</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71160</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: nf_tables: avoid chain re-validation if possible&lt;/p&gt;
&lt;p&gt;Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():&lt;/p&gt;
&lt;p&gt;watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
 RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_table_validate+0x6b/0xb0 [nf_tables]
  nf_tables_validate+0x8b/0xa0 [nf_tables]
  nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]&lt;/p&gt;
&lt;p&gt;Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps).  But there are cases where we could avoid revalidation.&lt;/p&gt;
&lt;p&gt;Consider:
1  input -&amp;gt; j2 -&amp;gt; j3
2  input -&amp;gt; j2 -&amp;gt; j3
3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3&lt;/p&gt;
&lt;p&gt;Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.&lt;/p&gt;
&lt;p&gt;This…&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;netfilter: nf_tables: avoid chain re-validation if possible&lt;/p&gt;
&lt;p&gt;Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():&lt;/p&gt;
&lt;p&gt;watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
 RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_table_validate+0x6b/0xb0 [nf_tables]
  nf_tables_validate+0x8b/0xa0 [nf_tables]
  nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]&lt;/p&gt;
&lt;p&gt;Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps).  But there are cases where we could avoid revalidation.&lt;/p&gt;
&lt;p&gt;Consider:
1  input -&amp;gt; j2 -&amp;gt; j3
2  input -&amp;gt; j2 -&amp;gt; j3
3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3&lt;/p&gt;
&lt;p&gt;Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.&lt;/p&gt;
&lt;p&gt;This…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71160</guid>
    </item>
    <item>
      <title>GHSA-3xmc-22wh-x2gr</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3xmc-22wh-x2gr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;netfilter: nf_tables: avoid chain re-validation if possible&lt;/p&gt;
&lt;p&gt;Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():&lt;/p&gt;
&lt;p&gt;watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
 RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_table_validate+0x6b/0xb0 [nf_tables]
  nf_tables_validate+0x8b/0xa0 [nf_tables]
  nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]&lt;/p&gt;
&lt;p&gt;Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps).  But there are cases where we could avoid revalidation.&lt;/p&gt;
&lt;p&gt;Consider:
1  input -&amp;gt; j2 -&amp;gt; j3
2  input -&amp;gt; j2 -&amp;gt; j3
3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3&lt;/p&gt;
&lt;p&gt;Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.&lt;/p&gt;
&lt;p&gt;This…&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;netfilter: nf_tables: avoid chain re-validation if possible&lt;/p&gt;
&lt;p&gt;Hamza Mahfooz reports cpu soft lock-ups in
nft_chain_validate():&lt;/p&gt;
&lt;p&gt;watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]
[..]
 RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]
[..]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_immediate_validate+0x36/0x50 [nf_tables]
  nft_chain_validate+0xc9/0x110 [nf_tables]
  nft_table_validate+0x6b/0xb0 [nf_tables]
  nf_tables_validate+0x8b/0xa0 [nf_tables]
  nf_tables_commit+0x1df/0x1eb0 [nf_tables]
[..]&lt;/p&gt;
&lt;p&gt;Currently nf_tables will traverse the entire table (chain graph), starting
from the entry points (base chains), exploring all possible paths
(chain jumps).  But there are cases where we could avoid revalidation.&lt;/p&gt;
&lt;p&gt;Consider:
1  input -&amp;gt; j2 -&amp;gt; j3
2  input -&amp;gt; j2 -&amp;gt; j3
3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3&lt;/p&gt;
&lt;p&gt;Then the second rule does not need to revalidate j2, and, by extension j3,
because this was already checked during validation of the first rule.
We need to validate it only for rule 3.&lt;/p&gt;
&lt;p&gt;This…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3xmc-22wh-x2gr</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-71160 — netfilter: nf_tables: avoid chain re-validation if possible</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-71160</link>
      <description>msrc_CVE-2025-71160</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-71160</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-2025-71160</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71160</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate():  watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..]  RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_table_validate+0x6b/0xb0 [nf_tables]   nf_tables_validate+0x8b/0xa0 [nf_tables]   nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps).  But there are cases where we could avoid revalidation. Consider: 1  input -&amp;gt; j2 -&amp;gt; j3 2  input -&amp;gt; j2 -&amp;gt; j3 3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is nee…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid chain re-validation if possible Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate():  watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..]  RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_table_validate+0x6b/0xb0 [nf_tables]   nf_tables_validate+0x8b/0xa0 [nf_tables]   nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps).  But there are cases where we could avoid revalidation. Consider: 1  input -&amp;gt; j2 -&amp;gt; j3 2  input -&amp;gt; j2 -&amp;gt; j3 3  input -&amp;gt; j1 -&amp;gt; j2 -&amp;gt; j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is nee…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71160</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0215 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0215</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-0215</guid>
    </item>
  </channel>
</rss>
