In the Linux kernel, the following vulnerability has been resolved:
ipv6: ndisc: fix NULL deref in acceptuntrackedna()
acceptuntrackedna() re-fetches the inet6_dev with __in6devget(dev) and dereferences idev->cnf.acceptuntrackedna without a NULL check, even though its only caller ndiscrecvna() already fetched and NULL-checked idev for the same device.
Both reads of dev->ip6ptr run in the same RCU read-side critical section, but a concurrent addrconfifdown() can clear dev->ip6ptr between them: lowering the MTU below IPV6MINMTU calls addrconfifdown() without the synchronize_net() that orders the unregister path, so the re-fetch returns NULL and oopses:
BUG: KASAN: null-ptr-deref in ndiscrecvna (net/ipv6/ndisc.c:974) Read of size 4 at addr 0000000000000364 Call Trace: <IRQ> ndiscrecvna (net/ipv6/ndisc.c:974) icmpv6rcv (net/ipv6/icmp.c:1193) ip6protocoldeliverrcu (net/ipv6/ip6input.c:479) ip6inputfinish (net/ipv6/ip6input.c:534) ip6input (net/ipv6/ip6input.c:545) ip6mcinput (net/ipv6/ip6input.c:635) ipv6rcv (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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64542.json"
}