CVE-2026-64542

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: ndisc: fix NULL deref in accept_untracked_na()<br /> <br /> accept_untracked_na() re-fetches the inet6_dev with __in6_dev_get(dev)<br /> and dereferences idev-&gt;cnf.accept_untracked_na without a NULL check,<br /> even though its only caller ndisc_recv_na() already fetched and<br /> NULL-checked idev for the same device.<br /> <br /> Both reads of dev-&gt;ip6_ptr run in the same RCU read-side critical<br /> section, but a concurrent addrconf_ifdown() can clear dev-&gt;ip6_ptr<br /> between them: lowering the MTU below IPV6_MIN_MTU calls addrconf_ifdown()<br /> without the synchronize_net() that orders the unregister path, so the<br /> re-fetch returns NULL and oopses:<br /> <br /> BUG: KASAN: null-ptr-deref in ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> Read of size 4 at addr 0000000000000364<br /> Call Trace:<br /> <br /> ndisc_recv_na (net/ipv6/ndisc.c:974)<br /> icmpv6_rcv (net/ipv6/icmp.c:1193)<br /> ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479)<br /> ip6_input_finish (net/ipv6/ip6_input.c:534)<br /> ip6_input (net/ipv6/ip6_input.c:545)<br /> ip6_mc_input (net/ipv6/ip6_input.c:635)<br /> ipv6_rcv (net/ipv6/ip6_input.c:351)<br /> <br /> <br /> It is reachable by an unprivileged user via a network namespace.<br /> <br /> Pass the caller&amp;#39;s already validated idev instead of re-fetching it; the<br /> idev stays alive for the whole RCU critical section, so it is safe even<br /> after dev-&gt;ip6_ptr has been cleared.