CVE-2026-63831High· 8.8▾ TwilightIn 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() …
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 48.4 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Aug 17.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.2%
0.2% → 0.3%
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:
Without this guard, in-place crypto on shared skb data leads to:
Found by 0sec (https://0sec.ai) using automated source analysis.
Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-64564Critical· 9.8In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport …
CVE-2026-63802High· 7.0In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur
CVE-2026-106071Low· 3.6nodejs: nodejs: Permission model bypass via wildcard path matching flaw (CVE-2026-106071)
CVE-2026-106070Low· 3.7nodejs: Node.js: Security inspection bypass via crafted ZIP archive header mismatch (CVE-2026-106070)
CVE-2026-98873Low· 3.3kernel: netfilter: nf_conntrack_expect: zero at allocation time (CVE-2026-98873)
CVE-2026-98871Medium· 4.1kernel: crypto: ccp - Fix possible deadlock in SEV init failure path (CVE-2026-98871)