CVE-2026-63870

What it actually does

This is a Linux kernel 6LoWPAN transmit-path memory-safety flaw. When a non-IPv6 packet is queued for transmission through an IEEE 802.15.4 6LoWPAN interface, the 6LoWPAN header creation path may return before initializing address metadata in the packet buffer headroom. The later transmit function then unconditionally reads and uses that uninitialized metadata. In kernel context, use of uninitialized memory can cause information disclosure, memory corruption, kernel crashes, or potentially privilege escalation depending on reachable code paths, compiler behavior, kernel configuration, and surrounding memory state. The CVSS vector indicates local, low-complexity exploitation requiring low privileges and no user interaction, with potential high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using Linux kernels with IEEE 802.15.4 or Bluetooth 6LoWPAN functionality may be exposed to local attackers who can transmit crafted non-IPv6 traffic through a configured 6LoWPAN interface. Successful exploitation could lead to system instability, service outages, leakage of sensitive kernel memory, or elevated privileges. The risk is highest for embedded, IoT, industrial, wireless sensor, and gateway systems where 6LoWPAN support is enabled or exposed to local users/containers. It is not currently listed in CISA KEV, has no known mature public exploit in the provided data, and has a low EPSS score, so remediation should be prioritized based on local exposure to 6LoWPAN interfaces rather than treated as an internet-wide emergency.

How an attack unfolds

An attacker first needs local access or a foothold that permits them to cause packets to be transmitted through a configured 6LoWPAN network interface. They then generate a non-IPv6 packet, such as an AoE Ethernet protocol frame or similar unsupported protocol type, and route or queue it to the 6LoWPAN interface via the normal kernel transmit path. Because 6LoWPAN is intended to carry IPv6, the header creation routine exits early for the non-IPv6 packet and leaves address information in the skb headroom uninitialized. The transmit path later assumes that metadata is valid, copies it, and uses it while preparing the outgoing frame. Depending on the stale memory contents and kernel build, this may result in a crash, unintended memory disclosure, corrupted protocol state, or a condition that can be shaped toward local privilege escalation. Exploitation is constrained by the need for local privileges and a reachable 6LoWPAN transmit path, but environments using wireless low-power networking or embedded Linux builds should consider the affected code path realistic.

How to fix it

Apply a Linux kernel update that includes the fix to drop non-IPv6 packets before they reach the vulnerable 6LoWPAN transmit handling. Because no exact fixed package versions were provided, use the relevant vendor advisory for the deployed distribution, appliance, embedded firmware, or kernel branch and verify that the patch for the IEEE 802.15.4 6LoWPAN lowpan_xmit path, and the analogous Bluetooth 6LoWPAN bt_xmit path where applicable, is included. If immediate patching is not possible, reduce exposure by disabling unused 6LoWPAN, IEEE 802.15.4, Bluetooth 6LoWPAN, and related kernel modules or interfaces; preventing untrusted users and containers from creating or manipulating 6LoWPAN network interfaces; restricting CAP_NET_ADMIN and raw packet capabilities; and limiting local shell access on affected systems. For embedded products, obtain updated firmware from the device or platform vendor.

How to confirm the fix worked

Confirm the running kernel version includes the upstream or vendor backport that rejects non-IPv6 packets in 6LoWPAN transmit paths. Validate through vendor package changelogs, kernel source inspection, or advisory references rather than version comparison alone, because distributions often backport fixes. Check whether 6LoWPAN support is loaded or available by reviewing kernel modules and interfaces, such as ieee802154, 6lowpan, bluetooth 6lowpan, wpan, and lowpan interfaces. Confirm mitigations by verifying unused modules are not loaded, affected interfaces are absent or administratively disabled, and unprivileged users/containers cannot create or transmit through 6LoWPAN interfaces. In a controlled test environment only, sending non-IPv6 traffic through a 6LoWPAN interface should be dropped cleanly without kernel warnings, oops messages, crashes, or unexpected transmission behavior.

Typical attack path

1. Gain local code execution or a low-privileged account on a Linux system with 6LoWPAN support available.
2. Identify or configure an IEEE 802.15.4 or Bluetooth 6LoWPAN interface capable of transmitting packets.
3. Generate a non-IPv6 packet, for example an AoE or other unsupported Ethernet protocol frame.
4. Queue the packet for transmission through the 6LoWPAN interface using the normal networking stack.
5. Trigger the header creation path to return without initializing 6LoWPAN address metadata.
6. Cause the transmit path to consume uninitialized skb headroom data, potentially leading to kernel crash, information exposure, memory corruption, or privilege escalation.

How to detect it

Look for evidence of attempted exploitation in kernel, audit, endpoint, and network-management logs. Primary sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd, container runtime logs, and any EDR telemetry that records module loading, network namespace creation, privileged container execution, or raw packet tooling. Investigate kernel warnings, oops, panics, soft lockups, BUG reports, KASAN/KMSAN reports, or crashes occurring near 6LoWPAN, IEEE 802.15.4, Bluetooth 6LoWPAN, wpan, lowpan, skb, or netdevice transmit functions. Review commands and audit events showing creation or manipulation of lowpan/wpan interfaces, loading of ieee802154 or 6lowpan modules, granting of CAP_NET_ADMIN or CAP_NET_RAW, or execution of packet-generation tools. Network telemetry may be limited because exploitation is local and occurs in the kernel transmit path, but non-IPv6 protocol traffic being directed to a 6LoWPAN interface, especially AoE/ETH_P_AOE or other unexpected EtherTypes, is suspicious. There are no provided reports of active exploitation, named threat actors, ransomware use, or public exploit maturity, so detections should focus on local abuse patterns and crash forensics rather than known campaign indicators.

• lowpan_xmit
• bt_xmit
• lowpan_header
• setup_header
• lowpan_header_create
• header_create
• ieee802154
• 6lowpan
• bluetooth 6lowpan
• wpan
• lowpan
• ETH_P_AOE
• AoE
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• kernel BUG
• Oops:
• general protection fault
• KASAN:
• KMSAN:
• WARNING: CPU:
• NETDEV WATCHDOG
• modprobe ieee802154
• modprobe 6lowpan
• modprobe bluetooth_6lowpan
• ip link add link
• ip link set type lowpan
• iwpan dev

What your security team should do

• Inventory Linux systems, embedded devices, gateways, and IoT platforms that enable IEEE 802.15.4, Bluetooth 6LoWPAN, wpan, or lowpan networking.
• Prioritize patching systems where untrusted local users, containers, workloads, or field-accessible operators can interact with network interfaces or hold network administration capabilities.
• Apply vendor kernel or firmware updates that include the 6LoWPAN non-IPv6 packet drop fix.
• Disable unused 6LoWPAN, IEEE 802.15.4, Bluetooth 6LoWPAN, and related kernel modules or interfaces until patching is complete.
• Restrict CAP_NET_ADMIN, CAP_NET_RAW, privileged containers, and access to tools that can create or transmit crafted link-layer traffic.
• Monitor kernel logs for 6LoWPAN-related warnings, kernel oops events, crashes, or suspicious local interface manipulation.
• Treat unexplained crashes on systems using low-power wireless networking as potentially security-relevant until patched and reviewed.