<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T16:05:52.129782+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97974</id>
    <title>fkie_cve-2026-97974</title>
    <updated>2026-09-28T16:05:52.370387+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()</p>
<p>syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0].</p>
<p>The stack trace hinted towards a null dereference of rt-&gt;fib6_node when
fn-&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-&gt;tb6_lock.</p>
<p>Between ip6_route_del() looking up the route and __ip6_del_rt_siblings()
acquiring table-&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-&gt;fib6_node = NULL. A reproducer was found that triggers this [1].</p>
<p>Add a check to ensure rt-&gt;fib6_node is non-null before accessing it.</p>
<p>[0]
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056
Call Trace:
 &lt;TASK&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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-97974"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-2j2r-fxqg-mc3v</id>
    <title>GHSA-2j2r-fxqg-mc3v</title>
    <updated>2026-09-28T16:05:52.370576+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings()</p>
<p>syzbot reported a null-ptr-deref in __ip6_del_rt_siblings() [0].</p>
<p>The stack trace hinted towards a null dereference of rt-&gt;fib6_node when
fn-&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-&gt;tb6_lock.</p>
<p>Between ip6_route_del() looking up the route and __ip6_del_rt_siblings()
acquiring table-&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-&gt;fib6_node = NULL. A reproducer was found that triggers this [1].</p>
<p>Add a check to ensure rt-&gt;fib6_node is non-null before accessing it.</p>
<p>[0]
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
RIP: 0010:__ip6_del_rt_siblings+0x31e/0x7c0 net/ipv6/route.c:4056
Call Trace:
 &lt;TASK&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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-2j2r-fxqg-mc3v"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97974</id>
    <title>UBUNTU-CVE-2026-97974</title>
    <updated>2026-09-28T16:05:52.370656+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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</p>
<p>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-&gt;fib6_node when fn-&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-&gt;tb6_lock. Between ip6_route_del() looking up the route and __ip6_del_rt_siblings() acquiring table-&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-&gt;fib6_node = NULL. A reproducer was found that triggers this [1]. Add a check to ensure rt-&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:  &lt;TASK&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/…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97974"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</id>
    <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-09-28T16:05:52.371474+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579"/>
  </entry>
</feed>
