CVE-2026-68136

What it actually does

This Linux kernel networking flaw allows packets that have already been marked for GRO flush to be incorrectly re-aggregated by skb_gro_receive_list(). In forwarding, tethering, or similar multi-interface packet paths, already-aggregated packets with an existing frag_list can be aggregated a second time, corrupting the skb frag_list chain. When the transmit path later calls skb_segment() to segment the malformed packet, the kernel can dereference invalid or NULL skb pointers, resulting in a kernel panic. The primary technical impact is denial of service through kernel crash; there is no current indication of code execution or privilege escalation.

Why it matters to the business

Successful exploitation can crash affected Linux systems that process the triggering network traffic, causing service outages, interrupted connectivity, dropped network sessions, and potential disruption to routers, gateways, appliances, mobile tethering devices, virtualization hosts, or servers performing packet forwarding. The issue is newly published, not listed in CISA KEV, not associated with ransomware use, and has no reported mature exploit, but kernel networking crashes can still have high operational impact where availability is critical.

How an attack unfolds

An attacker would need to deliver or influence network traffic that reaches an affected Linux kernel path where packets are received as, or converted into, aggregated packets using LRO/GRO and then forwarded or transmitted through another interface. The attacker shapes traffic so that a packet already carrying a frag_list is marked with the GRO flush flag. Due to the missing flush validation in skb_gro_receive_list(), the packet may be accepted into a new GRO aggregation session instead of being flushed. This double aggregation corrupts the internal skb frag_list structure. When the system later attempts to transmit the packet and skb_segment() processes the malformed chain, it can encounter invalid state or a NULL/corrupted skb pointer and panic the kernel, taking the host or network device offline until it reboots or is manually recovered.

How to fix it

Apply a Linux kernel update from the relevant distribution or vendor that includes the fix adding NAPI_GRO_CB(skb)->flush validation to skb_gro_receive_list(). Because no affected product list or exact fixed package versions were provided, security teams should track the fix through their Linux distribution advisories and kernel stable update channels. Where immediate patching is not possible, consider temporary mitigations for exposed forwarding systems: disable GRO, LRO, or GSO/TSO on affected interfaces using ethtool where operationally feasible; reduce exposure of systems performing packet forwarding; and prioritize patching routers, gateways, firewalls, tethering devices, virtualization hosts, and high-availability network nodes. Mitigations that disable offload features may reduce throughput or increase CPU load and should be tested before broad deployment.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor fix for this issue, not merely that the package is installed. Reboot into the patched kernel where required. On Linux systems, compare uname -r and package manager output against the distribution advisory for the fixed kernel build. If mitigations are used, validate interface offload settings with commands such as ethtool -k <interface> and confirm that gro, lro, gso, tso, or related offloads are disabled as intended. For exposure validation, identify systems with IP forwarding, bridging, routing, tethering, container networking, virtualization networking, or appliance-style packet forwarding enabled, especially where GRO/LRO/GSO-capable NICs are present.

Typical attack path

1. Identify an affected Linux system that receives and forwards or retransmits network traffic through GRO/LRO/GSO-capable interfaces.
2. Send or induce a packet flow that results in already-aggregated packets with frag_list data being processed by the vulnerable GRO list path.
3. Cause a flush-marked skb to re-enter GRO handling where skb_gro_receive_list() is used.
4. Trigger incorrect re-aggregation because the flush flag is not honored in that function.
5. Allow the corrupted skb frag_list chain to proceed to the transmit path.
6. Cause skb_segment() or related GSO segmentation functions to process the corrupted structure.
7. Trigger a kernel panic and denial of service.

How to detect it

Look for evidence of kernel crashes, oops events, or panic traces in kernel and system logs rather than user-space compromise artifacts. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore records, netconsole output, hypervisor console logs, and out-of-band management event logs. Focus on call traces containing skb_segment(), skb_headlen(), tcp_gso_segment(), inet_gso_segment(), skb_mac_gso_segment(), validate_xmit_skb(), sch_direct_xmit(), qdisc_restart(), or net_tx_action. Correlate crashes with network forwarding, bridging, routing, tethering, virtualization traffic, or recent changes to NIC offload settings. There are no known public exploit-specific packet signatures from the provided data, so detection should prioritize crash forensics and recurrence patterns over static network IOCs.

• skb_segment
• skb_headlen
• 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
• NAPI_GRO_CB
• frag_list
• GRO
• GSO
• kernel panic
• Kernel panic
• BUG: kernel NULL pointer dereference
• Oops:
• Call Trace:

What your security team should do

• Prioritize patching Linux systems that perform packet forwarding, routing, bridging, NAT, tethering, VPN termination, virtualization networking, or network-appliance functions.
• Track vendor and distribution kernel advisories for the exact fixed kernel build and ensure systems are rebooted into the patched kernel after installation.
• If patching must be delayed, evaluate disabling GRO/LRO/GSO/TSO on exposed forwarding interfaces as a temporary mitigation, balancing availability protection against performance impact.
• Search kernel logs for recent panics or oops traces involving skb_segment, skb_headlen, GRO, GSO, or frag_list corruption.
• Monitor for repeated crashes on network-facing Linux devices, especially crashes correlated with high-throughput forwarding or unusual packet aggregation behavior.
• Because the issue is not currently listed in KEV and has no known mature exploit, treat it as urgent for availability-critical network infrastructure rather than as evidence of active compromise by default.