CVE-2026-53091

What it actually does

The flaw is in Linux kernel network packet handling for Generic Segmentation Offload (GSO) packets. The kernel’s queuing discipline code could inspect a packet header without ensuring the required header bytes were pulled into the linear portion of the socket buffer before later transmit-path processing. Some network drivers and TCP segmentation offload helpers assume those headers are already present in skb->head; a malformed or malicious GSO packet could violate that assumption and lead to invalid memory access during packet transmission. The most likely impact is a kernel crash or network stack instability, with potential broader memory-safety consequences depending on driver behavior and platform configuration.

Why it matters to the business

Successful exploitation could cause affected Linux systems to become unstable, lose networking, or crash, creating service downtime for workloads that depend on kernel networking. The risk is currently lower because there is no known public exploit maturity, it is not listed in CISA KEV, it is not associated with ransomware use, and EPSS is low; however, kernel networking flaws should still be prioritized on internet-facing, multi-tenant, virtualization, container, routing, VPN, and high-throughput systems because a crash can directly affect availability.

How an attack unfolds

An attacker first needs a way to introduce or cause the kernel to process a malformed GSO packet whose headers are not present where the transmit path expects them. Depending on system configuration, plausible sources include local packet-generation capabilities, virtual network devices, tunneling interfaces, container or VM networking paths, or software components that can hand crafted sk_buffs to the kernel networking stack. The malformed packet reaches queuing discipline processing, where packet length and segment information are derived without forcing the relevant headers into the skb linear data area. Later, the packet is passed toward a network driver or TSO helper that assumes those headers are linear and copies from skb->data. That mismatch can trigger an invalid memory read or related kernel fault, potentially crashing the host or disrupting networking. The fix changes validation behavior so the kernel pulls the required headers first and drops malformed GSO packets earlier with a bad-GSO drop reason.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for qdisc_pkt_len_segs_init() using pskb_may_pull() and dropping malformed GSO packets with SKB_DROP_REASON_SKB_BAD_GSO. Because no affected product or fixed-version list was provided, use the relevant Linux distribution security advisory or vendor kernel changelog to identify the patched kernel package for each platform. Prioritize kernel updates on systems that expose complex networking paths, including routers, firewalls, load balancers, Kubernetes/container hosts, hypervisors, VPN gateways, tunneling endpoints, and systems allowing untrusted users or workloads to create raw packets, virtual interfaces, or tunneled traffic. If immediate patching is not possible, reduce exposure by limiting untrusted local packet-generation privileges, restricting CAP_NET_RAW and CAP_NET_ADMIN in containers, disabling unnecessary tunneling or virtual network interfaces, and reviewing offload/qdisc configurations where operationally feasible. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm exposure by identifying Linux kernel versions in use and comparing them against the distribution or vendor advisory that contains the qdisc_pkt_len_segs_init() header-pull fix. Validate remediation by booting into the patched kernel, confirming the running kernel version with standard host inventory commands, and verifying that vulnerable kernel packages are no longer active after reboot. Where available, review kernel changelogs or source packages for the patch that replaces skb_header_pointer-style inspection with pskb_may_pull() in the GSO qdisc path and introduces or references SKB_DROP_REASON_SKB_BAD_GSO. For runtime validation, monitor kernel logs and packet-drop telemetry for malformed GSO drops rather than crashes; a patched system should reject bad GSO packets earlier instead of allowing them into vulnerable transmit-driver paths.

Typical attack path

1. Obtain a path to inject or generate crafted network traffic that is processed as a GSO packet by the Linux kernel.
2. Craft a malformed GSO packet where required protocol headers are not present in the skb linear header area.
3. Send the packet through a network path that uses qdisc processing and a driver or transmit offload path expecting headers in skb->head.
4. Trigger transmit-side header handling, such as TSO header construction, that copies header bytes from an unexpected memory location.
5. Cause kernel networking instability, packet drops, interface disruption, or a host crash if the invalid access is not safely handled.

How to detect it

Post-exploitation detection is difficult because this issue is most likely to manifest as kernel instability or denial of service rather than a durable file, process, or account artifact. Review kernel logs, crash dumps, netconsole output, hypervisor logs, and centralized syslog for crashes or warnings in the network transmit path, especially near qdisc, GSO, TSO, skb, or NIC driver activity. Look for sudden host reboots, kernel oops/panic events, NETDEV watchdog timeouts, interface resets, transmit queue hangs, or crash stacks referencing qdisc_pkt_len_segs_init(), tso_build_hdr(), net/core/tso.c, dev_hard_start_xmit(), sch_* qdisc code, or NIC ndo_start_xmit handlers. On patched systems, monitor drop tracing or kernel telemetry for malformed GSO packets using the SKB_DROP_REASON_SKB_BAD_GSO reason; repeated drops may indicate probing or exploitation attempts. Correlate suspicious events with local users, containers, VMs, VPN sessions, virtual interfaces, TUN/TAP devices, and packet-generation tools active immediately before the crash. Network-only detection may be unreliable because the malformed condition can be created or transformed inside the host networking stack rather than appearing as a simple wire-level signature.

• SKB_DROP_REASON_SKB_BAD_GSO
• SKB_BAD_GSO
• qdisc_pkt_len_segs_init
• tso_build_hdr
• net/core/tso.c
• dev_hard_start_xmit
• ndo_start_xmit
• NETDEV WATCHDOG
• transmit queue timed out
• kernel BUG at net/core/tso.c
• general protection fault
• kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems running affected kernel families, especially hosts performing routing, virtualization, container networking, tunneling, or high-throughput packet forwarding.
• Patch and reboot priority systems first, then complete fleet-wide kernel remediation through normal maintenance windows.
• Use vendor-specific advisories to map the fix to exact distribution kernel package versions because fixed versions were not provided in the input.
• Restrict untrusted workloads from using CAP_NET_RAW, CAP_NET_ADMIN, raw sockets, TUN/TAP devices, or privileged container networking unless required.
• Review container, VM, VPN, and SDN platforms for paths where untrusted tenants or workloads can generate GSO or offloaded traffic.
• Enable or tune monitoring for kernel oops, panic, NETDEV watchdog, driver transmit faults, and abnormal malformed-GSO drop events.
• Treat repeated unexplained kernel networking crashes as potentially security-relevant until patched and investigated.
• Because EPSS is low, not KEV-listed, and no mature exploit is known, prioritize based on exposure and availability requirements rather than emergency internet-wide exploitation assumptions.