CVE-2026-64542

Published: Lug 27, 2026 Last Modified: Lug 27, 2026
ExploitDB:
Other exploit source:
Google Dorks:

Description

AI Translation Available

In the Linux kernel, the following vulnerability has been resolved:

ipv6: ndisc: fix NULL deref in accept_untracked_na()

accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)
and dereferences idev->cnf.accept_untracked_na without a NULL check,
even though its only caller ndisc_recv_na() already fetched and
NULL-checked idev for the same device.

Both reads of dev->ip6_ptr run in the same RCU read-side critical
section, but a concurrent addrconf_ifdown() can clear dev->ip6_ptr
between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown()
without the synchronize_net() that orders the unregister path, so the
re-fetch returns NULL and oopses:

BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974)
Read of size 4 at addr 0000000000000364
Call Trace:
<IRQ>
ndisc_recv_na (net/ipv6/ndisc.c:974)
icmpv6_rcv (net/ipv6/icmp.c:1193)
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)
ip6_input_finish (net/ipv6/ip6_input.c:534)
ip6_input (net/ipv6/ip6_input.c:545)
ip6_mc_input (net/ipv6/ip6_input.c:635)
ipv6_rcv (net/ipv6/ip6_input.c:351)
</IRQ>

It is reachable by an unprivileged user via a network namespace.

Pass the caller's already validated idev instead of re-fetching it; the
idev stays alive for the whole RCU critical section, so it is safe even
after dev->ip6_ptr has been cleared.

https://git.kernel.org/stable/c/62c719203cb521b64fab74da94a81bdde5c18808
https://git.kernel.org/stable/c/63d1c23764de2309cedbb779c75188d257a09d9b
https://git.kernel.org/stable/c/a6450f7cfae57b382cbaf66a577765c9a88b3c58
https://git.kernel.org/stable/c/d186e942365acece7c56d39da05dd63bf95b280a