CVE-2026-89561
massNULL Pointer Dereference in Linux Kernel IPv6 RPL Routing Header Processing
A race condition in the Linux kernel's IPv6 RPL (Routing Protocol for Low-Power and Lossy Networks) source-routing-header reception path causes a NULL pointer dereference in ipv6_rpl_srh_rcv(), which reads idev->cnf.rpl_seg_enabled without a NULL check after obtaining it via __in6_dev_get(). Lowering an interface's MTU below IPV6_MIN_MTU (1280) makes addrconf_ifdown() clear dev->ip6_ptr, so an IPv6 packet carrying an RPL routing header that already passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with idev NULL, crashing the kernel (reproduced by flooding ping6 traffic while flapping MTU between 1500 and 1200). An attacker who can deliver RPL routing-header packets to a host while the interface MTU drops below 1280 triggers a KASAN null-ptr-deref panic, yielding denial of service only (CVSS 7.5, no confidentiality or integrity impact). Any Linux system running a kernel with this code path and accepting IPv6 routing headers is affected in principle, though exploitation requires winning the race between packet arrival and the MTU-driven teardown. There is no public PoC, the CVE is not in CISA's KEV catalog, and no exploitation is known in the wild.
What to do: Upgrade to a kernel containing the fix, which validates idev in ipv6_rthdr_rcv() before dispatching to either SRH handler (affected packets are then dropped with SKB_DROP_REASON_IPV6DISABLED), and check your distribution's kernel package for the backport. Until patched, drop IPv6 routing-header type 3 (RPL) packets at the network edge via ip6tables/nftables and avoid administrative or automated changes that push interface MTU below 1280 on production systems. Watch kernel logs for null-ptr-deref panics in ipv6_rpl_srh_rcv as an indicator of triggering attempts.
| Linux kernel | Versions prior to the fixing commit (which adds an idev NULL check in ipv6_rthdr_rcv() before calling ipv6_rpl_srh_rcv() and ipv6_srh_rcv()); vulnerability conf |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled. When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL. Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200: BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070 Read of size 4 at addr 00000000000006b4 by task ping6/394 CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full) Call Trace: kasan_report+0xc6/0x100 ipv6_rpl_srh_rcv+0xb3/0x1070 ip6_protocol_deliver_rcu+0x759/0x9a0 ip6_input_finish+0xa8/0x1b0 ip6_input+0xe1/0x490 ipv6_rcv+0x33d/0x460 __netif_receive_skb_one_core+0xd6/0x130 process_backlog+0x2cc/0xa00 __napi_poll.constprop.0+0x56/0x270 net_rx_action+0x327/0x730 handle_softirqs+0x11e/0x630 do_softirq+0xb3/0xf0 Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup. Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.