PT-2026-65217 · Linux · Linux
CVE-2026-64542
·
Published
2026-07-27
·
Updated
2026-07-27
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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:
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)
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux