CVE-2026-63831 in Linux
Summary
by MITRE • 07/19/2026
In the Linux kernel, the following vulnerability has been resolved:
mac802154: llsec: add skb_cow_data() before in-place crypto
llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt).
On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference.
On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true).
The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by:
- ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c)
Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free)
Found by 0sec (https://0sec.ai) using automated source analysis.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/19/2026
The vulnerability resides in the linux kernel's mac802154 subsystem where insecure in-place cryptographic operations on shared socket buffer (skb) data lead to potential data corruption and system instability. This issue affects the llsec functionality within the 802.15.4 wireless networking implementation which handles link layer security for low-power wireless networks. The flaw occurs when cryptographic functions perform direct modifications on skb data without ensuring exclusive access to that memory region, creating a race condition scenario where multiple references to the same underlying buffer can be simultaneously modified.
The technical implementation involves four specific functions - llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() - which all utilize scatterlist structures created with sg_init_one() pointing directly into the skb's linear data area. These functions then pass identical scatterlists as both source and destination parameters to crypto API operations such as crypto_skcipher_encrypt/decrypt and crypto_aead_encrypt/decrypt. The problem manifests during both transmission and reception paths where skbs can be cloned through reference counting mechanisms, causing multiple consumers to share the same memory buffer.
During packet reception, __ieee802154_rx_handle_packet() creates cloned skbs for distribution to multiple subscribers via ieee802154_subif_frame(), establishing shared references to the original data buffer. When llsec_do_decrypt() subsequently modifies this shared buffer in-place, it corrupts data that other clones referencing the same memory location may still need or use. Similarly on transmission paths, when skb_cloned() returns true, data sharing occurs between the original and cloned buffers leading to identical corruption risks.
The solution implements a defensive programming pattern by calling skb_cow_data() before any in-place cryptographic operation, as recommended by industry standards and established practices within kernel security frameworks. This function ensures that the skb's data area is not shared by copying data into a private buffer when the skb head is cloned or when data spans multiple fragments, making subsequent modifications safe. The fix follows patterns already established in other secure kernel subsystems including ESP implementations in net/ipv4/esp4.c and net/ipv6/esp6.c, MACsec drivers/net/macsec.c, WireGuard drivers/net/wireguard/receive.c, and TIPC net/tipc/crypto.c implementations.
Without proper mitigation, this vulnerability creates severe operational impacts including silent data corruption that affects other skb clones, use-after-free conditions when the crypto API scatterwalk writes to pages already freed by kfree_skb() operations from other clone references, and kernel crashes under concurrent 802.15.4 traffic with security enabled as evidenced by KASAN/KMSAN reports of slab-use-after-free errors. The vulnerability affects systems running linux kernel versions where the mac802154 subsystem handles security-enabled 802.15.4 communications, particularly those implementing link layer security protocols that depend on in-place cryptographic transformations of network frames.
This issue aligns with CWE-129 Input Validation and Output Processing, specifically addressing improper handling of shared memory resources during cryptographic operations. From an ATT&CK perspective, this represents a privilege escalation vector through kernel memory corruption (T1068) and potentially system instability leading to denial of service conditions. The vulnerability was discovered through automated source analysis by 0sec team, highlighting the importance of systematic code review approaches in identifying subtle security flaws in kernel networking subsystems that can affect network reliability and data integrity across wireless communication platforms.
The fix implementation directly addresses the root cause by ensuring proper memory isolation before cryptographic operations, preventing concurrent modification scenarios that could compromise system stability. This approach aligns with secure coding practices recommended for kernel developers and represents a standard defensive mechanism against shared memory race conditions in cryptographic contexts. The solution maintains compatibility while eliminating the potential for data corruption and system crashes that could otherwise occur during normal network operation with security features enabled.