<?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 12:27:15 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-74656</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-74656</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-74656</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1090 — 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-1090</link>
      <description>certfr-2026-avi-1090</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1090</guid>
    </item>
    <item>
      <title>EUVD-2026-358537</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-358537</link>
      <description>EUVD-2026-358537</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-358537</guid>
    </item>
    <item>
      <title>fkie_cve-2026-74656</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-74656</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv4: fix use-after-free in fib_nhc_update_mtu()&lt;/p&gt;
&lt;p&gt;fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but
RTNL does not serialize this walk with PMTU exception updates. The walk
uses rcu_dereference_protected() with a constant true condition without
holding fnhe_lock.&lt;/p&gt;
&lt;p&gt;The following interleaving can therefore occur:&lt;/p&gt;
&lt;p&gt;CPU 0                              CPU 1
  fib_nhc_update_mtu()               update_or_create_fnhe()
    load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)
                                       fnhe_remove_oldest()
                                         unlink fnhe
                                         kfree_rcu(fnhe, rcu)
    &amp;lt;quiescent state&amp;gt;
    access fnhe after grace period&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410
  Read of size 8 at addr ffff888107d49000 by task poc/90
  Call Trace:
   fib_nhc_update_mtu+0x3df/0x410
   fib_sync_mtu+0x7a/0xd0
   fib_netdev_event+0x229/0x3f0
   netif_set_mtu_ext+0x33a/0x570
   dev_set_mtu+0x88/0x120&lt;/p&gt;
&lt;p&gt;The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a
pair and other writers serialize them with fnhe_lock. RCU alone prevents
reclamation, but would still allow concurrent writers to leave a mixed
pair.&lt;/p&gt;
&lt;p&gt;Walk the table under RCU and acquire fnhe_lock only while updating each
exception. RCU keeps the current entry alive while the short critical
section serializes it…&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;ipv4: fix use-after-free in fib_nhc_update_mtu()&lt;/p&gt;
&lt;p&gt;fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but
RTNL does not serialize this walk with PMTU exception updates. The walk
uses rcu_dereference_protected() with a constant true condition without
holding fnhe_lock.&lt;/p&gt;
&lt;p&gt;The following interleaving can therefore occur:&lt;/p&gt;
&lt;p&gt;CPU 0                              CPU 1
  fib_nhc_update_mtu()               update_or_create_fnhe()
    load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)
                                       fnhe_remove_oldest()
                                         unlink fnhe
                                         kfree_rcu(fnhe, rcu)
    &amp;lt;quiescent state&amp;gt;
    access fnhe after grace period&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410
  Read of size 8 at addr ffff888107d49000 by task poc/90
  Call Trace:
   fib_nhc_update_mtu+0x3df/0x410
   fib_sync_mtu+0x7a/0xd0
   fib_netdev_event+0x229/0x3f0
   netif_set_mtu_ext+0x33a/0x570
   dev_set_mtu+0x88/0x120&lt;/p&gt;
&lt;p&gt;The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a
pair and other writers serialize them with fnhe_lock. RCU alone prevents
reclamation, but would still allow concurrent writers to leave a mixed
pair.&lt;/p&gt;
&lt;p&gt;Walk the table under RCU and acquire fnhe_lock only while updating each
exception. RCU keeps the current entry alive while the short critical
section serializes it…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-74656</guid>
    </item>
    <item>
      <title>GHSA-4hv8-gc9j-4wjf</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4hv8-gc9j-4wjf</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv4: fix use-after-free in fib_nhc_update_mtu()&lt;/p&gt;
&lt;p&gt;fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but
RTNL does not serialize this walk with PMTU exception updates. The walk
uses rcu_dereference_protected() with a constant true condition without
holding fnhe_lock.&lt;/p&gt;
&lt;p&gt;The following interleaving can therefore occur:&lt;/p&gt;
&lt;p&gt;CPU 0                              CPU 1
  fib_nhc_update_mtu()               update_or_create_fnhe()
    load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)
                                       fnhe_remove_oldest()
                                         unlink fnhe
                                         kfree_rcu(fnhe, rcu)
    &amp;lt;quiescent state&amp;gt;
    access fnhe after grace period&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410
  Read of size 8 at addr ffff888107d49000 by task poc/90
  Call Trace:
   fib_nhc_update_mtu+0x3df/0x410
   fib_sync_mtu+0x7a/0xd0
   fib_netdev_event+0x229/0x3f0
   netif_set_mtu_ext+0x33a/0x570
   dev_set_mtu+0x88/0x120&lt;/p&gt;
&lt;p&gt;The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a
pair and other writers serialize them with fnhe_lock. RCU alone prevents
reclamation, but would still allow concurrent writers to leave a mixed
pair.&lt;/p&gt;
&lt;p&gt;Walk the table under RCU and acquire fnhe_lock only while updating each
exception. RCU keeps the current entry alive while the short critical
section serializes it…&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;ipv4: fix use-after-free in fib_nhc_update_mtu()&lt;/p&gt;
&lt;p&gt;fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but
RTNL does not serialize this walk with PMTU exception updates. The walk
uses rcu_dereference_protected() with a constant true condition without
holding fnhe_lock.&lt;/p&gt;
&lt;p&gt;The following interleaving can therefore occur:&lt;/p&gt;
&lt;p&gt;CPU 0                              CPU 1
  fib_nhc_update_mtu()               update_or_create_fnhe()
    load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)
                                       fnhe_remove_oldest()
                                         unlink fnhe
                                         kfree_rcu(fnhe, rcu)
    &amp;lt;quiescent state&amp;gt;
    access fnhe after grace period&lt;/p&gt;
&lt;p&gt;KASAN reported:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410
  Read of size 8 at addr ffff888107d49000 by task poc/90
  Call Trace:
   fib_nhc_update_mtu+0x3df/0x410
   fib_sync_mtu+0x7a/0xd0
   fib_netdev_event+0x229/0x3f0
   netif_set_mtu_ext+0x33a/0x570
   dev_set_mtu+0x88/0x120&lt;/p&gt;
&lt;p&gt;The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a
pair and other writers serialize them with fnhe_lock. RCU alone prevents
reclamation, but would still allow concurrent writers to leave a mixed
pair.&lt;/p&gt;
&lt;p&gt;Walk the table under RCU and acquire fnhe_lock only while updating each
exception. RCU keeps the current entry alive while the short critical
section serializes it…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-4hv8-gc9j-4wjf</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-74656 — ipv4: fix use-after-free in fib_nhc_update_mtu()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-74656</link>
      <description>msrc_CVE-2026-74656</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-74656</guid>
    </item>
    <item>
      <title>OESA-2026-3707 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3707</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;seg6: separate dst_cache for input and output paths in seg6 lwtunnel&lt;/p&gt;
&lt;p&gt;The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.&lt;/p&gt;
&lt;p&gt;Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE&lt;/p&gt;
&lt;p&gt;The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr-&amp;amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.&lt;/p&gt;
&lt;p&gt;ib_sg_to_page() has ensured that when i&amp;amp;gt;=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr-&amp;amp;gt;page_size aligned.&lt;/p&gt;
&lt;p&gt;This leads to incorrect iova-to-va conversion in scenarios:&lt;/p&gt;
&lt;p&gt;1) page_size &amp;amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;amp;gt;iova = 0x1…&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;seg6: separate dst_cache for input and output paths in seg6 lwtunnel&lt;/p&gt;
&lt;p&gt;The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.&lt;/p&gt;
&lt;p&gt;Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE&lt;/p&gt;
&lt;p&gt;The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr-&amp;amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.&lt;/p&gt;
&lt;p&gt;ib_sg_to_page() has ensured that when i&amp;amp;gt;=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr-&amp;amp;gt;page_size aligned.&lt;/p&gt;
&lt;p&gt;This leads to incorrect iova-to-va conversion in scenarios:&lt;/p&gt;
&lt;p&gt;1) page_size &amp;amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;amp;gt;iova = 0x1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3707</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-74656</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74656</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 242 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur:   CPU 0                              CPU 1   fib_nhc_update_mtu()               update_or_create_fnhe()     load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)                                        fnhe_remove_oldest()                                          unlink fnhe                                          kfree_rcu(fnhe, rcu)     &amp;lt;quiescent state&amp;gt;     access fnhe after grace period KASAN reported:   BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410   Read of size 8 at addr ffff888107d49000 by task poc/90   Call Trace:    fib_nhc_update_mtu+0x3df/0x410    fib_sync_mtu+0x7a/0xd0    fib_netdev_event+0x229/0x3f0    netif_set_mtu_ext+0x33a/0x570    dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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, Ubuntu:16.04:LTS: linux-hwe-edge and 242 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipv4: fix use-after-free in fib_nhc_update_mtu() fib_nhc_update_mtu() walks the nexthop exception table under RTNL, but RTNL does not serialize this walk with PMTU exception updates. The walk uses rcu_dereference_protected() with a constant true condition without holding fnhe_lock. The following interleaving can therefore occur:   CPU 0                              CPU 1   fib_nhc_update_mtu()               update_or_create_fnhe()     load fnhe                          spin_lock_bh(&amp;amp;fnhe_lock)                                        fnhe_remove_oldest()                                          unlink fnhe                                          kfree_rcu(fnhe, rcu)     &amp;lt;quiescent state&amp;gt;     access fnhe after grace period KASAN reported:   BUG: KASAN: slab-use-after-free in fib_nhc_update_mtu+0x3df/0x410   Read of size 8 at addr ffff888107d49000 by task poc/90   Call Trace:    fib_nhc_update_mtu+0x3df/0x410    fib_sync_mtu+0x7a/0xd0    fib_netdev_event+0x229/0x3f0    netif_set_mtu_ext+0x33a/0x570    dev_set_mtu+0x88/0x120 The same walk updates fnhe_pmtu and fnhe_mtu_locked. These fields form a pair and other writers serialize them with fnhe_lock. RCU alone prevents reclamation, but would still allow concurrent writers to leave a mixed pair. Walk the table under RCU and acquire fnhe_lock only while updating each exception. RCU keeps the current entry alive while the short critical section serializes its paired…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74656</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2970 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</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, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&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, einen Denial-of-Service-Zustand herbeizuführen oder vertrauliche Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2970</guid>
    </item>
  </channel>
</rss>
