<?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://vulnerability.circl.lu</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, 29 Sep 2026 10:45:14 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-97974 — ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-97974</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()&lt;/p&gt;
&lt;p&gt;syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0].&lt;/p&gt;
&lt;p&gt;The stack trace hinted towards a null dereference of rt-&amp;gt;fib6_node when
fn-&amp;gt;leaf is accessed in __ip6_del_rt_siblings(). With
RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run
concurrently without acquiring the RTNL lock. In ip6_route_del(), the
route lookup happens under rcu_read_lock() without acquiring
table-&amp;gt;tb6_lock.&lt;/p&gt;
&lt;p&gt;Between ip6_route_del() looking up the route and __ip6_del_rt_siblings()
acquiring table-&amp;gt;tb6_lock, another thread can modify the routing table.
For example, when an ECMP route is replaced via RTM_NEWROUTE with
NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets
iter-&amp;gt;fib6_node = NULL. A reproducer was found that triggers this [1].&lt;/p&gt;
&lt;p&gt;Add a check to ensure rt-&amp;gt;fib6_node is non-null before accessing it.&lt;/p&gt;
&lt;p&gt;[0]
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056
Call Trace:
 &amp;lt;TASK&amp;gt;
 ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232
 inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669
 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132
 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x813/0xb4…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()&lt;/p&gt;
&lt;p&gt;syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0].&lt;/p&gt;
&lt;p&gt;The stack trace hinted towards a null dereference of rt-&amp;gt;fib6_node when
fn-&amp;gt;leaf is accessed in __ip6_del_rt_siblings(). With
RTNL_FLAG_DOIT_UNLOCKED set, inet6_rtm_delroute() operations run
concurrently without acquiring the RTNL lock. In ip6_route_del(), the
route lookup happens under rcu_read_lock() without acquiring
table-&amp;gt;tb6_lock.&lt;/p&gt;
&lt;p&gt;Between ip6_route_del() looking up the route and __ip6_del_rt_siblings()
acquiring table-&amp;gt;tb6_lock, another thread can modify the routing table.
For example, when an ECMP route is replaced via RTM_NEWROUTE with
NLM_F_REPLACE, fib6_add_rt2node() unlinks all old siblings and sets
iter-&amp;gt;fib6_node = NULL. A reproducer was found that triggers this [1].&lt;/p&gt;
&lt;p&gt;Add a check to ensure rt-&amp;gt;fib6_node is non-null before accessing it.&lt;/p&gt;
&lt;p&gt;[0]
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056
Call Trace:
 &amp;lt;TASK&amp;gt;
 ip6_route_del+0x1054/0x1110 net/ipv6/route.c:4232
 inet6_rtm_delroute+0x5d7/0x6d0 net/ipv6/route.c:5669
 rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7132
 netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x7f5/0x990 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x813/0xb4…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-97974</guid>
    </item>
  </channel>
</rss>
