CVE-2026-64452

What it actually does

This is a Linux kernel use-after-free in the 6LoWPAN Next Header Compression (NHC) decompression path. A malformed 6LoWPAN packet can cause lowpan_nhc_do_uncompression() to follow an error path where lowpan_nhc_lock is released before the code prints nhc->name. If another execution context unregisters and frees the same NHC descriptor during that window, the kernel can dereference freed memory. The reported impact is high because kernel use-after-free conditions can potentially cause memory corruption, kernel crash, information disclosure, or, in favorable conditions, privilege escalation or code execution in kernel context. Exploitation is constrained by adjacency, race timing, and the need to interact with 6LoWPAN/Bluetooth 6LoWPAN receive paths or related module lifecycle behavior.

Why it matters to the business

Systems using Linux 6LoWPAN, IEEE 802.15.4, or Bluetooth 6LoWPAN functionality may be exposed to crashes or deeper kernel compromise from a nearby attacker able to deliver malformed low-power network traffic. Operationally, the most likely consequence is denial of service on embedded, IoT, gateway, or wireless-enabled Linux systems; the worst case is compromise of the host kernel. The EPSS score is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but the kernel-level impact warrants prioritization for devices that actually enable 6LoWPAN-related networking.

How an attack unfolds

An attacker first needs adjacency to a vulnerable 6LoWPAN-capable communication path, such as an IEEE 802.15.4 or Bluetooth 6LoWPAN receive path, and must be able to cause the target to process a malformed compressed 6LoWPAN header. The malformed packet is crafted so decompression finds an NHC descriptor that lacks an uncompress callback, forcing the error path in lowpan_nhc_do_uncompression(). During the narrow window after the lock is dropped but before the warning reads nhc->name, another context must unregister and free the descriptor. If the race is won, the original path dereferences freed kernel memory. Depending on kernel configuration, allocator behavior, hardening, and attacker control over heap layout, this may result in a kernel warning, KASAN finding, crash, or potentially exploitable memory corruption. The bug is difficult to exploit reliably because it depends on precise timing and descriptor unregister/free behavior, and there is no indication of public weaponized exploitation from the supplied data.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for the 6LoWPAN NHC error-path use-after-free. No exact fixed versions were provided in the input, so use the relevant distribution, appliance, or device-vendor advisory to identify the first non-vulnerable kernel build. Where immediate patching is not possible, reduce exposure by disabling unused 6LoWPAN, IEEE 802.15.4, and Bluetooth 6LoWPAN functionality; preventing untrusted adjacent devices from communicating with affected radios; and restricting the ability to load or unload related kernel modules. Kernel hardening features such as module signing, lockdown, KASLR, SLUB/KASAN diagnostics in test builds, and strict access controls can reduce exploitability but do not replace patching.

How to confirm the fix worked

Confirm that the running kernel includes the patch that moves the warning access to nhc->name while lowpan_nhc_lock is still held. Validate through vendor package metadata, kernel changelog, or source inspection for the fixed lowpan_nhc_do_uncompression() behavior. Check whether 6LoWPAN functionality is present or active by reviewing kernel configuration and loaded modules for 6LOWPAN, IEEE802154, Bluetooth 6LoWPAN, and lowpan-related components. After remediation, perform a controlled reboot if required so the fixed kernel is actually running, then verify with uname/package inventory and confirm no vulnerable kernel remains bootable by default. In lab validation, malformed 6LoWPAN decompression tests should reject unsupported packets without KASAN, kernel oops, panic, or use-after-free reports.

Typical attack path

1. Identify a Linux target that has 6LoWPAN-related networking enabled, such as IEEE 802.15.4 or Bluetooth 6LoWPAN support.
2. Establish adjacent access to the relevant low-power wireless or local network medium.
3. Send a malformed 6LoWPAN packet that reaches lowpan_header_decompress() and triggers the NHC decompression error path.
4. Induce or race against NHC descriptor unregistration/freeing, such as module removal or descriptor lifecycle activity, while the error path is active.
5. Win the race so the decompression path reads nhc->name after the descriptor has been freed.
6. Cause a kernel use-after-free condition, leading to a crash, diagnostic report, or potentially exploitable kernel memory corruption.

How to detect it

Look for evidence of attempted or successful exploitation in kernel logs, crash dumps, and endpoint telemetry. Relevant sources include dmesg, journald, syslog/kern.log, kdump/vmcore analysis, kernel oops/panic records, KASAN reports on debug kernels, audit logs for kernel module load/unload activity, Bluetooth daemon logs, IEEE 802.15.4/6LoWPAN interface logs, and wireless packet captures where available. Investigate any slab-use-after-free reports involving lowpan_nhc_do_uncompression() or lowpan_header_decompress(), especially when accompanied by malformed 6LoWPAN traffic or recent unload/removal of lowpan/NHC-related modules. For production systems without KASAN, suspicious indicators may be spontaneous kernel crashes, soft lockups, general protection faults, NULL/invalid pointer dereferences, or panics with lowpan, nhc, bluetooth_6lowpan, or ieee802154 functions in the stack trace. Network-level detection is difficult without protocol-aware 6LoWPAN visibility, but malformed compressed 6LoWPAN headers, repeated decompression failures, or anomalous Bluetooth L2CAP traffic to 6LoWPAN paths should be reviewed.

• BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression
• slab-use-after-free in lowpan_nhc_do_uncompression
• lowpan_nhc_do_uncompression
• lowpan_header_decompress
• lowpan_nhc_del
• Read of size 8
• KASAN: slab-use-after-free
• 6lowpan
• bluetooth_6lowpan
• ieee802154
• nhc->name

What your security team should do

• Prioritize patching Linux systems that enable 6LoWPAN, IEEE 802.15.4, Bluetooth 6LoWPAN, or low-power wireless gateway functionality.
• If those features are unused, disable the relevant kernel modules and interfaces to remove the exposed code path.
• Track vendor advisories for exact fixed kernel package versions because no per-product fixed versions were supplied.
• Restrict physical and radio adjacency to affected devices, especially embedded gateways and IoT concentrators that process untrusted low-power wireless traffic.
• Monitor kernel logs for KASAN, slab use-after-free, oops, panic, and lowpan_nhc_do_uncompression/lowpan_header_decompress stack traces.
• Treat crashes in lowpan or Bluetooth 6LoWPAN receive paths as security-relevant until ruled out.
• Because KEV is false, ransomware use is false, EPSS is low, and exploit maturity is listed as none, prioritize based on actual feature exposure rather than fleet-wide emergency response.