CVE-2026-53235

What it actually does

This flaw is a Linux kernel networking denial-of-service vulnerability in the Generic Receive Offload (GRO) receive path. Under specific packet-buffer conditions, skb_gro_receive_list() calls skb_pull() without first ensuring the needed bytes are present in the skb linear data area. If a packet arrives through napi_gro_frags() with data stored in page fragments and a non-zero GRO offset, the kernel can hit BUG_ON(skb->len < skb->data_len) in __skb_pull(), causing a kernel BUG/panic depending on system configuration. The practical technical impact is a remotely triggerable or network-adjacent kernel crash if an attacker can deliver crafted network traffic that exercises the vulnerable GRO path.

Why it matters to the business

Successful exploitation can crash affected Linux systems or disrupt network processing, causing service outages, dropped connections, failover events, or node reboots. The risk is highest for internet-facing, high-throughput, or packet-processing Linux hosts such as load balancers, firewalls, proxies, Kubernetes nodes, virtualization hosts, storage appliances, and servers with GRO enabled. EPSS is currently low and there is no known CISA KEV listing or reported ransomware use, but kernel-networking denial-of-service issues can still create material operational impact when exposed systems process untrusted traffic.

How an attack unfolds

An attacker sends crafted network traffic that reaches a vulnerable Linux network interface and is processed by the NAPI/GRO receive path. The packet layout must cause GRO parsing to establish a non-zero skb_gro_offset while the packet data remains in non-linear page fragments, such that skb_headlen may be zero or insufficient. When the GRO list receive helper processes the skb, it calls skb_pull() without first calling pskb_may_pull() to linearize or validate the required bytes. This violates skb_pull() preconditions and can trigger the kernel BUG_ON check in __skb_pull(). If the kernel is configured to panic on BUG or the fault is unrecoverable in context, the host may crash, reboot, or lose networking service. There is no evidence in the provided data of public exploit maturity, named threat actor use, KEV listing, or ransomware campaign use.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the fix adding pskb_may_pull() validation in skb_gro_receive_list(). Because fixed package versions were not provided, use the advisory from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainer to identify the exact patched kernel release. Prioritize systems that process untrusted network traffic, use high-throughput NICs, or serve as network infrastructure. If immediate patching is not possible, consider temporary mitigations such as disabling GRO/LRO on exposed interfaces where operationally acceptable, restricting untrusted network reachability, applying rate limits or upstream filtering, and ensuring HA/failover capacity can absorb node crashes. Temporary offload changes should be tested carefully because they may affect throughput and CPU utilization.

How to confirm the fix worked

Confirm that each system is running a kernel build that includes the upstream or vendor backport for the skb_gro_receive_list() pskb_may_pull() fix. Validate using distribution package metadata, vendor security advisories, kernel changelogs, or source inspection for the added pskb_may_pull() guard in the GRO receive path. On Linux systems, verify the running kernel with commands such as uname -r and package-manager queries, then compare against the vendor-fixed release. For mitigation validation, check interface offload state with ethtool -k <interface> and confirm generic-receive-offload is disabled only where that mitigation is intentionally applied. After remediation, monitor for absence of recurring kernel BUG/panic traces involving __skb_pull(), skb_pull(), napi_gro_frags(), or skb_gro_receive_list() under normal and high-volume network traffic.

Typical attack path

1. Identify a Linux system that accepts attacker-controlled network traffic and uses a vulnerable kernel build with GRO/NAPI processing enabled.
2. Send specially formed TCP or UDP traffic that is processed through napi_gro_frags() and skb_gro_receive_list().
3. Cause the packet buffer to have insufficient linear data while retaining a non-zero GRO offset after protocol parsing.
4. Trigger skb_pull() on a non-linear skb without the required pskb_may_pull() guard.
5. Cause a kernel BUG/panic in __skb_pull(), resulting in denial of service, reboot, or network disruption.

How to detect it

To determine whether this issue may already have been triggered, review kernel logs, system journals, crash dumps, and centralized logging for kernel BUG, panic, oops, or call traces involving the Linux skb/GRO receive path. Primary sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg archives, kdump/vmcore data, hypervisor reset events, BMC/IPMI logs, cloud instance system logs, and network device telemetry around the time of outages. Look for abrupt reboots or network-service interruptions preceded by BUG_ON or assertion failures in __skb_pull(), skb_pull(), skb_gro_receive_list(), napi_gro_frags(), or related GRO functions. Network evidence may be limited because exploitation causes a crash rather than leaving a durable file artifact; correlate crashes with bursts of unusual TCP/UDP traffic, fragmented or offloaded receive traffic, interface error spikes, or traffic from untrusted sources immediately before the event. Absence of these artifacts does not prove non-exploitation because volatile kernel logs can be lost during panic/reboot unless persistent logging or crash dumping is enabled.

• BUG_ON(skb->len < skb->data_len)
• kernel BUG at net/core/skbuff.c
• kernel BUG in __skb_pull
• __skb_pull
• skb_pull
• skb_gro_receive_list
• napi_gro_frags
• pskb_may_pull
• NAPI_GRO_CB
• skb->len < skb->data_len
• Call Trace:
• Kernel panic - not syncing
• Oops:
• general protection fault
• net/core/skbuff.c

What your security team should do

• Inventory Linux systems and appliances exposed to untrusted network traffic and identify running kernel versions.
• Prioritize patching internet-facing servers, load balancers, firewalls, proxies, container hosts, hypervisors, and high-throughput network nodes.
• Apply vendor kernel updates that include the skb_gro_receive_list() pskb_may_pull() fix; reboot systems where required to load the patched kernel.
• Where patching is delayed, evaluate disabling GRO on exposed interfaces using ethtool, with performance testing and rollback planning.
• Add monitoring for kernel BUG, panic, or oops events referencing __skb_pull(), skb_pull(), skb_gro_receive_list(), napi_gro_frags(), or GRO receive processing.
• Review recent unexplained crashes or reboots on network-facing Linux hosts for evidence consistent with this fault.
• Ensure HA, clustering, and load-balancing configurations can tolerate abrupt node loss until patching is complete.