<?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>Mon, 28 Sep 2026 16:05:52 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-97974</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97974</link>
      <description>&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;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/fkie_cve-2026-97974</guid>
    </item>
    <item>
      <title>GHSA-2j2r-fxqg-mc3v</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-2j2r-fxqg-mc3v</link>
      <description>&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;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/ghsa-2j2r-fxqg-mc3v</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97974</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97974</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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0]. 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. 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]. Add a check to ensure rt-&amp;gt;fib6_node is non-null before accessing it. [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/0xb40 net/…&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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0]. 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. 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]. Add a check to ensure rt-&amp;gt;fib6_node is non-null before accessing it. [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/0xb40 net/…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97974</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
