CVE-2026-68136 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
net: gro: fix double aggregation of flush-marked skbs
Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO packet.") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation.
As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated.
This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic.
Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list
Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) {
When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs.
Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action
Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability resides within the Linux kernel's Generic Receive Offload (GRO) subsystem, specifically affecting how packets are aggregated and processed during network ingress. This issue stems from an inconsistent implementation of flush validation between two related functions: skb_gro_receive() and skb_gro_receive_list(). The commit 0ab03f353d36 introduced a flush check in skb_gro_receive() to prevent processing of packets marked for flushing, but failed to apply the same safeguard to skb_gro_receive_list(). This discrepancy creates a scenario where packets that should be excluded from further aggregation due to their flush status can still undergo re-aggregation. The flaw manifests when network drivers utilize Large Receive Offload (LRO) to create aggregated packets with frag_list structures, which are then processed through the GRO mechanism.
The technical execution of this vulnerability occurs during packet forwarding operations in tethering or device-to-device scenarios where packets flow through multiple network interfaces. When a driver generates an aggregated packet P1 via LRO with a frag_list structure, subsequent processing at Device A receives the packet with NAPI_GRO_CB(skb)->flush flag properly set to indicate that this packet should not be re-aggregated. However, when Device A re-enters the GRO subsystem and calls skb_gro_receive_list(), the missing flush validation allows the packet to proceed through aggregation logic despite its flush flag. This leads to a corruption of the frag_list chain structure as already-GRO'd packets with existing frag_list are re-aggregated into new GRO sessions, creating loops or dangling references within the packet fragmentation data structures.
The operational impact of this vulnerability reaches critical levels when packets with corrupted frag_lists attempt to traverse the transmission path. During TX processing, when skb_segment() is invoked to unpack these malformed packets, it encounters invalid state conditions that trigger kernel panics. The corruption occurs specifically in the skb_segment() function around line 4891 where checks for header size and fragment count occur, but fail when dealing with NULL pointers from corrupted frag_list references. When list_skb becomes a NULL pointer from skb->next and the code attempts to dereference skb_headlen(list_skb), it accesses invalid memory locations causing system crashes. This represents a direct violation of kernel stability principles and can result in complete system hangs or reboots.
The root cause analysis reveals that this vulnerability stems from a defensive programming inconsistency within the networking subsystem, where the same validation pattern exists in one function but not its counterpart. The flaw directly correlates to CWE-129, which addresses improper validation of array indices and buffer bounds, as well as CWE-476, concerning null pointer dereferences. From an ATT&CK framework perspective, this vulnerability maps to T1059.001 (Command and Scripting Interpreter: PowerShell) through potential exploitation of kernel-level command execution paths, though more specifically relates to T1499.004 (Endpoint Denial of Service: File and Directory Permissions) due to the system stability compromise. The fix implements a consistent defensive programming pattern by adding NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching exactly what exists in skb_gro_receive().
Mitigation strategies should focus on immediate kernel updates that apply the patch addressing the flush validation inconsistency. Network administrators should also monitor for system stability issues that might indicate exploitation attempts, particularly in environments with high packet aggregation rates or complex network topologies involving multiple device forwarding paths. The fix represents a defensive programming best practice that prevents similar issues in related code paths and aligns with kernel security hardening principles that emphasize consistency in validation patterns across subsystem interfaces. Organizations should prioritize patching this vulnerability as it can be exploited to cause denial of service conditions that may affect network connectivity and system availability, particularly in mobile or embedded environments where tethering functionality is prevalent.