CVE-2026-63984

What it actually does

This flaw is an integer truncation and bounds-checking error in the Linux kernel IPv6 RPL Source Routing Header decompression path. A crafted IPv6 RPL routing header with an excessive number of decompressed segments can cause the computed header length to overflow an 8-bit field, making the kernel place the compressed header over the decompressed header buffer. Subsequent recompression can corrupt the routing header of a forwarded packet and may cause kernel memory corruption, packet misrouting, denial of service, or potentially broader compromise depending on kernel build, memory layout, and reachable code paths. The issue is remotely reachable over the network where IPv6 RPL processing is enabled or reachable, requires no authentication, and requires no user interaction.

Why it matters to the business

Systems that route or process IPv6 RPL traffic could be disrupted or potentially compromised by a remote attacker sending specially crafted IPv6 packets. The highest operational risk is to Linux-based routers, gateways, embedded systems, IoT infrastructure, and network appliances using IPv6 RPL functionality. Although this vulnerability has a critical CVSS score, current EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is indicated, so organizations should prioritize exposed routing infrastructure and kernel upgrade cycles rather than assume widespread active exploitation.

How an attack unfolds

An attacker with network reachability to a Linux system that processes IPv6 RPL Source Routing Headers crafts an IPv6 packet containing an RPL compressed source routing header with values that cause the decompressed segment count to reach the vulnerable boundary. In the vulnerable kernel path, ipv6_rpl_srh_decompress() calculates a header length that exceeds the capacity of the 8-bit hdrlen field; for example, a decompressed length equivalent to 256 is truncated to 0. The receiving or forwarding path then uses the truncated value to place the compressed header at the wrong offset, overlapping data that was already decompressed. When ipv6_rpl_srh_compress() operates on the overlapping data, it corrupts the routing header of the packet being forwarded. Depending on the system role and kernel behavior, this can result in malformed forwarding behavior, kernel instability, denial of service, or potentially exploitable memory corruption.

How to fix it

Upgrade to a Linux kernel version that includes the ipv6 RPL hdrlen bounds fix, which tightens the allowed decompressed segment count so the computed RPL header length cannot overflow the 8-bit hdrlen field. If vendor fixed versions are not yet mapped for a distribution, apply the latest security kernel update from the relevant Linux distribution or appliance vendor and confirm that the patch for ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() is included. As interim mitigation, restrict or drop IPv6 Routing Headers and RPL Source Routing Headers at network boundaries and on hosts that do not explicitly require RPL. Disable unnecessary IPv6 forwarding and RPL-related functionality where operationally feasible. Prioritize routers, gateways, IoT border routers, embedded Linux devices, and externally reachable systems that process IPv6 extension headers.

How to confirm the fix worked

Confirm the running kernel includes the vendor security update or upstream patch for ipv6_rpl_srh_decompress() that rejects cases where n + 1 is greater than 127. Validate both the installed kernel package and the currently booted kernel, because patched packages are not effective until the system is rebooted into the updated kernel. Review kernel changelogs, distribution advisories, or source patches for the tightened bound in the IPv6 RPL SRH decompression logic. From a network-control perspective, verify that IPv6 Routing Header type 3 / RPL-related traffic is blocked or allowed only where required. Where safe testing is authorized, use packet-capture or controlled validation tooling to confirm that malformed high-segment-count RPL headers are rejected or do not cause kernel warnings, crashes, packet corruption, or forwarding anomalies.

Typical attack path

1. Identify Linux systems that route or process IPv6 traffic and may have RPL Source Routing Header handling reachable.
2. Send probe traffic to determine whether IPv6 extension headers and RPL routing headers are accepted rather than filtered.
3. Craft an IPv6 packet with an RPL Source Routing Header using boundary values that produce an excessive decompressed segment count, such as the n=127 class of condition described in the fix.
4. Deliver the malicious packet to the target directly or through a routed IPv6 path that causes the vulnerable kernel to process the RPL header.
5. Trigger the vulnerable decompression and recompression logic, causing header-length truncation and buffer overlap.
6. Leverage the result for denial of service, packet corruption, misrouting, or further exploitation if reliable kernel memory corruption is achievable.

How to detect it

Look for evidence of attempted delivery of malformed IPv6 RPL Source Routing Headers and for host symptoms consistent with kernel handling failure. Network detection should use packet captures, IDS/IPS telemetry, firewall logs, router flow records, and network sensor metadata to identify IPv6 packets containing RPL Source Routing Headers, especially unusually large compressed source-route headers, high segment counts, or suspicious combinations such as maximum compression parameters. Host detection should review kernel logs, crash dumps, kdump/vmcore artifacts, systemd-journald, dmesg, appliance logs, and availability monitoring for kernel oops, panic, BUG, warning, soft lockup, RCU stall, general protection fault, slab corruption, unexpected reboot, or forwarding anomalies near times when unusual IPv6 extension-header traffic was observed. Because there are no widely published exploit indicators or named threat actors for this issue, detection should focus on behavioral evidence: anomalous IPv6 Routing Header type 3/RPL traffic, malformed extension headers, repeated packet-processing faults, and sudden instability on systems that route IPv6.

• ipv6_rpl_srh_decompress
• ipv6_rpl_srh_rcv
• ipv6_rpl_srh_compress
• RPL Source Routing Header
• IPv6 Routing Header type 3
• IPV6-ROUTE
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• BUG: unable to handle kernel
• WARNING: CPU:
• soft lockup
• RCU stall
• skb_over_panic
• slab corruption
• unexpected IPv6 extension header
• malformed IPv6 routing header

What your security team should do

• Inventory Linux systems, appliances, containers with host networking dependencies, embedded devices, and IoT gateways that run affected kernels and process IPv6 traffic.
• Prioritize patching systems that perform IPv6 routing, forwarding, RPL, border-router, gateway, or network-appliance functions.
• Apply vendor kernel security updates and reboot into the patched kernel; verify the running kernel version after maintenance.
• Where RPL is not required, block IPv6 Routing Headers and RPL Source Routing Header traffic at firewalls, routers, host firewalls, and network security controls.
• Increase monitoring for malformed IPv6 extension headers, unusual RPL traffic, kernel crashes, soft lockups, warnings, packet-forwarding anomalies, and unexpected reboots.
• For embedded or vendor-managed appliances, obtain vendor confirmation that the kernel fix is included in firmware and schedule firmware updates promptly.
• Because this is not currently in CISA KEV and EPSS is low, balance urgency against exposure: treat internet-facing or untrusted IPv6-routing paths as high priority, and internal non-RPL hosts as standard kernel patching priority.