CVE-2026-89561: ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()
In the Linux kernel, the following vulnerability has been resolved:
ipv6: rpl: fix NULL dereference of idev in ipv6rplsrhrcv()
ipv6rplsrhrcv() dereferences idev from in6devget() without a NULL check when reading idev->cnf.rplsegenabled.
When the device's MTU drops below IPV6MINMTU, addrconfifdown() clears dev->ip6ptr through RCUINITPOINTER(). A packet that passed the idev check in ip6rcvcore() can then reach ipv6rplsrhrcv() with dev->ip6ptr 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 ipv6rplsrhrcv+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: <IRQ> kasanreport+0xc6/0x100 ipv6rplsrhrcv+0xb3/0x1070 ip6protocoldeliverrcu+0x759/0x9a0 ip6inputfinish+0xa8/0x1b0 ip6input+0xe1/0x490 ipv6rcv+0x33d/0x460 netifreceiveskbonecore+0xd6/0x130 processbacklog+0x2cc/0xa00 napipoll.constprop.0+0x56/0x270 netrxaction+0x327/0x730 handlesoftirqs+0x11e/0x630 dosoftirq+0xb3/0xf0 </IRQ>
Both ipv6rplsrhrcv() and ipv6srhrcv() are called only from ipv6rthdrrcv(), which already has an idev lookup.
Fix the NULL dereference on the RPL path by checking idev in ipv6rthdrrcv(), before it calls either function. The callees take idev as an argument and no longer call in6devget(), so the packet is now dropped in one place, with SKBDROPREASONIPV6DISABLED on both paths.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel ipv6 rplto a version that resolves this vulnerability.Patch ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() - Configuration
Fix the NULL dereference on the RPL path by checking the idev pointer (before evaluating idev->cnf.rpl_seg_enabled) in ipv6_rpl_srh_rcv().
Linux kernel IPv6 RPL Segment Routing Header receive path idev NULL-check before reading idev->cnf.rpl_seg_enabled = add check
Event History
Frequently Asked Questions
What conditions are needed to trigger the crash?
A packet must pass the earlier IPv6 device check and then reach ipv6_rpl_srh_rcv() after the receiving device's IPv6 state has been cleared. The reported reproduction floods the interface with ping6 traffic while repeatedly changing its MTU between 1500 and 1200, causing the MTU to drop below IPV6_MIN_MTU.
Who is realistically exposed?
Systems processing IPv6 traffic on an interface whose MTU can be changed below IPV6_MIN_MTU are exposed to the race described. Exposure depends on packets arriving during the interval after dev->ip6_ptr is cleared and before processing reaches ipv6_rpl_srh_rcv().
What can be done if the fix cannot be applied immediately?
Avoid changing affected receiving interfaces to an MTU below IPV6_MIN_MTU while they are handling IPv6 traffic. Reducing or preventing concurrent IPv6 packet traffic during required MTU changes also avoids the reported trigger conditions.
How can administrators recognize that this issue has occurred?
The reported failure is a KASAN null-pointer dereference in ipv6_rpl_srh_rcv(), reading from address 0x6b4. The stack trace includes ipv6_rpl_srh_rcv, ip6_protocol_deliver_rcu, ip6_input_finish, and IPv6 receive processing functions.