Cloudanix VulnDB

CVE-2026-89561

High · 7.5

CVSS

7.5

EPSS

0.4%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in network handling code can make systems crash when they receive certain internet traffic while network settings change, potentially knocking devices offline until restarted.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in ipv6_rpl_srh_rcv() when idev from __in6_dev_get() is NULL after MTU drop clears dev->ip6_ptr, leading to kernel crash on read of idev->cnf.rpl_seg_enabled.

Why it matters to the business

Remote denial of service that can crash affected Linux systems handling IPv6 traffic, disrupting network services and requiring reboots, with higher urgency for high-traffic environments exposed to RPL or MTU changes.

How an attack unfolds

An attacker sends crafted IPv6 packets with RPL routing headers or floods ping6 traffic while triggering MTU flapping below IPV6_MIN_MTU on the target interface, causing the kernel to reach ipv6_rpl_srh_rcv() with a cleared idev pointer and dereference it.

How to fix it

Apply kernel patches that perform idev NULL check in ipv6_rthdr_rcv() before invoking ipv6_rpl_srh_rcv() or ipv6_srh_rcv(), ensuring SKB_DROP_REASON_IPV6DISABLED on failure paths; rebuild and deploy updated kernel images across all affected systems.

How to confirm the fix worked

Confirm kernel source contains the idev check in ipv6_rthdr_rcv() prior to RPL/SRH calls, test by reproducing MTU flap with ping6 flood without crash, and verify no KASAN null-ptr-deref reports in logs under load.

Typical attack path

  1. Identify Linux host with IPv6 and RPL enabled on reachable interface
  2. Trigger or wait for MTU drop below minimum on target interface
  3. Send flood of IPv6 packets with RPL source routing header or ping6 traffic
  4. Cause ip6_rcv_core path to call ipv6_rthdr_rcv without idev check
  5. Trigger NULL dereference and kernel panic

How to detect it

Search kernel logs for KASAN null-ptr-deref reports mentioning ipv6_rpl_srh_rcv, ip6_protocol_deliver_rcu, or ipv6_rthdr_rcv; correlate with MTU change events and high volumes of IPv6 packets on affected interfaces.

What your security team should do

  • Prioritize kernel updates on all IPv6-enabled systems within 30 days
  • Disable RPL processing if not required via sysctl or kernel config
  • Monitor for interface MTU changes and unexpected IPv6 traffic spikes
  • Harden network edge to filter suspicious RPL headers

The record

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.

Affected packages

Ecosystem Package Introduced Fixed