ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv() (CVE-2026-89561) | HOL Guard CVE

Unknown severity · Source severity not reportedCVE-2026-89561

ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()

Answer in brief

CVE-2026-89561 records a Unknown severity vulnerability in ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Sep 11, 2026Updated Sep 11, 2026Source checked Sep 13, 2026First seen by HOL Sep 11, 2026Material review Sep 11, 2026

Upstream Advisory

Key facts

Risk: Unknown severitySource severity not reported
Exploitation: Not marked as known exploited
Affected software: 2 mapped packages or products
Fix availability: Available

Why this deserves its current priority

A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
Linux/Linuxgeneric	>=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <63f50e9f90d0287ad66a0955ebfc2d3a9c044a1c \|\| >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <eab3a917cdcb182542a3aac6a0d2d30659ca9821 \|\| >=8610c7c6e3bd647ff98d21c8bc0580e77bc2f8b3 <f826df95332c07380206dbd54178b6eefb311aba	63f50e9f90d0287ad66a0955ebfc2d3a9c044a1c, eab3a917cdcb182542a3aac6a0d2d30659ca9821, f826df95332c07380206dbd54178b6eefb311aba
Linux/Linuxgeneric	5.7	Not reported

Recommended response

Check inventory. Check lockfiles and deployed manifests for Linux/Linux, Linux/Linux.
Review the reported fix. Update Linux/Linux to 63f50e9f90d0287ad66a0955ebfc2d3a9c044a1c if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:record
Source modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:record
First seen by HOL
Sep 11, 2026

Sources and claim methodology

Upstream source description

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: <IRQ> 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 </IRQ> 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.

Quoted source text, attributed separately from HOL analysis.