CVE-2026-53235
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk37th percentile — higher than 37% of all known CVEs
Summary
A vulnerability was found in the Linux kernel's skb_gro_receive_list() function, which calls skb_pull() without first ensuring data is in the linear area via pskb_may_pull(). For packets arriving via napi_gro_frags(), this can trigger a BUG_ON assertion and system crash. The fix adds pskb_may_pull() and sets a flush flag on failure.
Risk Assessment
An attacker can send crafted network packets to trigger a kernel panic, causing denial of service on the affected system.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit adding pskb_may_pull() in skb_gro_receive_list()).
Original NVD description (English source)
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.