add pskb_may_pull to skb_gro_receive_list
Summary
In the Linux kernel, the following vulnerability has been resolved: net: add pskb_may_pull() to skb_gro_receive_list() skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling. A flaw was found in the Linux kernel's network Generic Receive Offload (GRO) handling. An attacker sending specially crafted network packets could trigger a bug in the `skb_gro_receive_list()` function. This occurs when the system attempts to process network data that is not in the expected linear memory area, leading to an incorrect buffer length calculation.
Mitigation
Mitigation steps weren't captured by the parser for this advisory — this is a parsing gap, not a statement that no fix exists. Read the vendor advisory below for the authoritative guidance.
Official advisory · medium-confidence parse· fetched 2 hours ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.