[PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto

[PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto

[Doruk Tan Ozturk]

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)

This vulnerability was identified using 0sec.ai, an open-source
automated security auditing platform (https://github.com/0sec-labs).

Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
Cc: stable@vger.kernel.org
Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
 net/mac802154/llsec.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index e8512578398e..b6a4a8c93d72 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -710,6 +710,7 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
 {
 	struct ieee802154_hdr hdr;
 	int rc, authlen, hlen;
+	struct sk_buff *trailer;
 	struct mac802154_llsec_key *key;
 	u32 frame_ctr;

@@ -769,6 +770,12 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
 	skb->mac_len = ieee802154_hdr_push(skb, &hdr);
 	skb_reset_mac_header(skb);

+	rc = skb_cow_data(skb, 0, &trailer);
+	if (rc < 0) {
+		llsec_key_put(key);
+		return rc;
+	}
+
 	rc = llsec_do_encrypt(skb, sec, &hdr, key);
 	llsec_key_put(key);

@@ -908,6 +915,13 @@ llsec_do_decrypt(struct sk_buff *skb, const struct mac802154_llsec *sec,
 		 const struct ieee802154_hdr *hdr,
 		 struct mac802154_llsec_key *key, __le64 dev_addr)
 {
+	struct sk_buff *trailer;
+	int err;
+
+	err = skb_cow_data(skb, 0, &trailer);
+	if (err < 0)
+		return err;
+
 	if (hdr->sec.level == IEEE802154_SCF_SECLEVEL_ENC)
 		return llsec_do_decrypt_unauth(skb, sec, hdr, key, dev_addr);
 	else
--
2.45.0

Re: [PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto

[Alexander Lobakin]

From: Doruk Tan Ozturk <doruk@0sec.ai>
Date: Mon, 25 May 2026 18:18:06 +0200

> [PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto

Pls mark as "PATCH net".

> 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)
> 
> This vulnerability was identified using 0sec.ai, an open-source
> automated security auditing platform (https://github.com/0sec-labs).
> 
> Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
> Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
> Cc: stable@vger.kernel.org
> Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>

Did you report this on LKML? If so, you should add

Closes: <link to your mail on lore>

right after the Reported-by.

> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Other than that,

Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>

Thanks,
Olek

[PATCH net v2] mac802154: llsec: add skb_cow_data() before in-place crypto

[Doruk Tan Ozturk]

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.

Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
Cc: stable@vger.kernel.org
Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Closes: https://lore.kernel.org/linux-wpan/20260525161806.96158-1-doruk@0sec.ai/
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2:
  - mark as net fix per Olek's review
  - add Closes tag
  - add Reviewed-by

 net/mac802154/llsec.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index e8512578398e..b6a4a8c93d72 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -710,6 +710,7 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
 {
 	struct ieee802154_hdr hdr;
 	int rc, authlen, hlen;
+	struct sk_buff *trailer;
 	struct mac802154_llsec_key *key;
 	u32 frame_ctr;

@@ -769,6 +770,12 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
 	skb->mac_len = ieee802154_hdr_push(skb, &hdr);
 	skb_reset_mac_header(skb);

+	rc = skb_cow_data(skb, 0, &trailer);
+	if (rc < 0) {
+		llsec_key_put(key);
+		return rc;
+	}
+
 	rc = llsec_do_encrypt(skb, sec, &hdr, key);
 	llsec_key_put(key);

@@ -908,6 +915,13 @@ llsec_do_decrypt(struct sk_buff *skb, const struct mac802154_llsec *sec,
 		 const struct ieee802154_hdr *hdr,
 		 struct mac802154_llsec_key *key, __le64 dev_addr)
 {
+	struct sk_buff *trailer;
+	int err;
+
+	err = skb_cow_data(skb, 0, &trailer);
+	if (err < 0)
+		return err;
+
 	if (hdr->sec.level == IEEE802154_SCF_SECLEVEL_ENC)
 		return llsec_do_decrypt_unauth(skb, sec, hdr, key, dev_addr);
 	else
--
2.45.0

Re: [PATCH net v2] mac802154: llsec: add skb_cow_data() before in-place crypto

[Simon Horman]

On Tue, May 26, 2026 at 08:37:26PM +0200, Doruk Tan Ozturk wrote:
> 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.
> 
> Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
> Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
> Cc: stable@vger.kernel.org
> Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
> Closes: https://lore.kernel.org/linux-wpan/20260525161806.96158-1-doruk@0sec.ai/
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> v2:
>   - mark as net fix per Olek's review
>   - add Closes tag
>   - add Reviewed-by

FTR: An AI generated review of this patch is available on sashiko.dev.
I believe that review can be treated in the context of possible follow-up
and should not effect the progress of this patch.