On 19/09/2026 at 21:28:55 GMT, Hui Peng <[email protected]> wrote: > In `dgram_ioctl()` (`SIOCINQ`), the queued skb at the head of > `sk->sk_receive_queue` has already had its MAC header stripped by > `ieee802154_subif_frame()` prior to `dgram_deliver()`, so `skb->len` is > already the exact payload length that `dgram_recvmsg()` will return to > userspace. > > However, `dgram_ioctl()` computes `*karg = skb->len - > ieee802154_hdr_length(skb)`. Calling `ieee802154_hdr_length(skb)` > re-parses the payload bytes as an 802.15.4 MAC header and calls > `pskb_may_pull(skb, ...)` while holding `sk->sk_receive_queue.lock`. > When multiple `SOCK_DGRAM` sockets receive a cloned copy of the frame > (`skb_shared(skb)` is true) and the payload is non-linear, > `pskb_may_pull()` calls `pskb_expand_head()`, which triggers > `BUG_ON(skb_shared(skb))`. Even on unshared linear skbs, subtracting > `ieee802154_hdr_length(skb)` a second time underflows `*karg` to a > negative value when the payload is shorter than the bogus parsed header > length. > > Set `*karg = skb->len` directly in `dgram_ioctl()`. > > Fixes: e1d001fa5b47 ("net: ioctl: Use kernel memory on protocol ioctl > callbacks") > Assisted-by: LLM > Signed-off-by: Hui Peng <[email protected]>
Looks legitimate. Reviewed-by: Miquel Raynal <[email protected]> Thanks, Miquèl
