CVE-2026-63831

What it actually does

This is a Linux kernel memory-safety flaw in the IEEE 802.15.4 mac802154 link-layer security implementation. The vulnerable code performs in-place encryption and decryption directly on socket buffer data without first ensuring that the buffer is privately owned. Because received 802.15.4 frames may be cloned and shared between multiple sockets or kernel subsystems, cryptographic writes can modify memory still referenced elsewhere. Under concurrent traffic, this can cause silent packet/data corruption, use-after-free conditions, kernel memory corruption, and kernel crashes. In worst-case conditions, kernel memory corruption may allow privilege escalation or arbitrary kernel-code execution, although exploitation is likely constrained to systems using 802.15.4 networking with link-layer security enabled and an attacker within adjacent radio/network range.

Why it matters to the business

Organizations using Linux-based 802.15.4, Zigbee-like, Thread, IoT gateway, industrial sensor, or embedded wireless systems may face device instability, data corruption, communication outages, and potential compromise of kernel-level integrity. A successful attack could crash affected gateways or endpoints, disrupt telemetry and control networks, or potentially allow deeper compromise of embedded Linux devices. The vulnerability has a high CVSS score but currently has low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so urgency is highest for environments that actively use IEEE 802.15.4 with link-layer security enabled or expose such radios to untrusted physical proximity.

How an attack unfolds

An attacker must be in adjacent network/radio range or otherwise able to send crafted IEEE 802.15.4 traffic to a vulnerable Linux system using mac802154 link-layer security. The attacker generates traffic patterns that cause the kernel receive path to clone socket buffers for multiple subscribers, then triggers link-layer security decryption that modifies shared skb data in place. Because the vulnerable code does not copy-on-write the skb data before crypto operations, writes performed by the crypto API can corrupt memory still referenced by another clone. Repeated or concurrent traffic can turn this into observable packet corruption, slab-use-after-free reports, or a kernel crash. On transmit paths, similar corruption may occur when crypto is applied to an skb whose head is already cloned. Practical exploitation beyond denial of service would require shaping memory layout and timing so that the use-after-free or corruption affects attacker-useful kernel objects.

How to fix it

Upgrade to a Linux kernel build from the device, distribution, or appliance vendor that includes the mac802154 LLSEC fix adding skb_cow_data() before in-place cryptographic operations. No exact fixed package versions were provided in the advisory input, so track vendor advisories for the specific kernel branch in use, including LTS and embedded BSP/vendor kernels. Where immediate patching is not possible, reduce exposure by disabling IEEE 802.15.4 interfaces, disabling mac802154 link-layer security where operationally safe, unloading unused 802.15.4-related kernel modules, restricting physical/radio access, and segmenting IoT/OT wireless gateways from higher-value networks. For embedded devices, ensure firmware images are rebuilt against a fixed kernel rather than only updating user-space packages.

How to confirm the fix worked

Confirm the running kernel contains the upstream or vendor backport that calls skb_cow_data() before LLSEC in-place encrypt/decrypt operations in mac802154. Validate by checking the installed kernel package changelog, vendor security advisory, kernel source, or build metadata for the CVE or the mac802154 LLSEC skb_cow_data fix. On systems where source is available, inspect the mac802154 LLSEC crypto paths for skb_cow_data() before calls to crypto_skcipher_encrypt(), crypto_skcipher_decrypt(), crypto_aead_encrypt(), or crypto_aead_decrypt(). Confirm whether 802.15.4 interfaces are present and active using standard Linux networking tools, and verify that mitigations such as disabled radios or unloaded modules remain persistent after reboot. After patching, run controlled 802.15.4 LLSEC traffic tests and confirm there are no new kernel oops, panic, KASAN, KMSAN, or slab-use-after-free messages referencing mac802154 LLSEC routines.

Typical attack path

1. Identify a Linux-based device using IEEE 802.15.4/mac802154 with link-layer security enabled.
2. Get within adjacent 802.15.4 radio range or gain another position that allows delivery of 802.15.4 frames to the target.
3. Send crafted or high-concurrency secured 802.15.4 traffic that exercises mac802154 LLSEC encryption/decryption paths.
4. Cause skb cloning and shared-buffer conditions in the receive or transmit path.
5. Trigger in-place cryptographic writes to shared skb data, resulting in memory corruption or use-after-free.
6. Repeat traffic to induce kernel warnings, data corruption, service instability, or a kernel panic; advanced attackers may attempt to shape corruption for privilege escalation.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel logs, crash dumps, and device telemetry from systems with IEEE 802.15.4 interfaces. Relevant sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, pstore/ramoops, kdump/vmcore analysis, embedded device crash reports, watchdog reset logs, and radio gateway monitoring records. Focus on kernel memory-corruption symptoms that coincide with 802.15.4 traffic bursts, LLSEC activity, or unexplained gateway resets. Search for KASAN, KMSAN, slab-use-after-free, general protection faults, kernel oops, BUG, panic, or call traces referencing mac802154 LLSEC routines such as llsec_do_decrypt_auth(), llsec_do_decrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_encrypt_unauth(), llsec_do_decrypt(), ieee802154_subif_frame(), or __ieee802154_rx_handle_packet(). Network-layer IoCs are difficult to define generically because exploitation depends on 802.15.4 frame handling and timing rather than a stable payload string; correlate crash timing with nearby/unexpected 802.15.4 devices, abnormal secured-frame rates, repeated association attempts, or anomalous radio traffic observed by 802.15.4 sniffers. If a vmcore is available, confirm whether the crashing task or stack involves mac802154 LLSEC crypto paths and shared skb/scatterlist handling.

• KASAN: slab-use-after-free
• KMSAN:
• BUG: KASAN:
• kernel BUG
• general protection fault
• Oops:
• Kernel panic
• slab-use-after-free
• use-after-free
• llsec_do_decrypt_auth
• llsec_do_decrypt_unauth
• llsec_do_encrypt_auth
• llsec_do_encrypt_unauth
• llsec_do_decrypt
• llsec_do_encrypt
• __ieee802154_rx_handle_packet
• ieee802154_subif_frame
• mac802154
• crypto_skcipher_decrypt
• crypto_skcipher_encrypt
• crypto_aead_decrypt
• crypto_aead_encrypt
• scatterwalk
• kfree_skb
• skb_cow_data

What your security team should do

• Inventory Linux systems, embedded gateways, IoT hubs, industrial controllers, and sensor platforms that use IEEE 802.15.4/mac802154 or related 802.15.4 radio hardware.
• Prioritize patching for devices with active 802.15.4 interfaces, link-layer security enabled, or radios reachable from untrusted physical locations.
• Obtain vendor kernel or firmware updates that include the mac802154 LLSEC skb_cow_data fix; for custom kernels, cherry-pick or backport the fix into all maintained branches.
• If patching is delayed, disable unused 802.15.4 radios, remove or block vulnerable kernel modules where feasible, and limit radio proximity exposure through physical controls.
• Monitor kernel logs for oops, panic, KASAN/KMSAN, slab-use-after-free, or stack traces involving mac802154 LLSEC functions.
• Treat unexplained crashes of 802.15.4 gateways as potentially security-relevant until logs and radio exposure have been reviewed.
• For products or appliances, request explicit confirmation from vendors that their shipped kernel includes the fix, especially for long-lived embedded Linux releases.