CVE-2026-43194

What it actually does

This Linux kernel networking flaw can cause established TCP connections to stall when Generic Segmentation Offload (GSO) traffic is transmitted through a qdisc-less path and the underlying network device reports transmit errors for individual segments. TCP may incorrectly treat a partially transmitted GSO frame as if the unsent portion was never transmitted, leaving sender and receiver sequence-number state inconsistent. The result is an availability failure: retransmissions and acknowledgements no longer make forward progress, causing affected connections to hang until reset or timed out.

Why it matters to the business

Systems that rely on affected Linux kernel networking paths may experience unexplained connection hangs, service timeouts, failed transfers, or degraded availability. The risk is highest for workloads using virtual networking, veth-style interfaces, container networking, XDP-enabled paths, disabled TSO/GSO offload behavior, or other qdisc-less device configurations where transmit errors can occur. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low, stable EPSS score, but it can still affect service reliability in exposed or high-throughput Linux networking environments.

How an attack unfolds

An attacker would need to trigger or influence TCP traffic over an affected Linux networking path where GSO frames are used and transmit failures can occur below TCP, such as certain virtual or qdisc-less network device configurations. By causing traffic bursts and packet drops or transmit errors at the right point in segmentation, some segments of a GSO frame can be delivered while others are treated by TCP as not sent. The receiver may acknowledge data beyond what the sender believes it transmitted. The sender then rejects those acknowledgements as referring to unsent data, retransmits older data, and the receiver continues acknowledging beyond the sender state. This feedback loop can leave the connection permanently stuck, creating a denial of service for that flow. There is no public exploit maturity reported and no named threat actor activity provided for this issue.

How to fix it

Apply Linux kernel updates from the relevant distribution or kernel vendor that include the fix for "net: consume xmit errors of GSO frames." No exact fixed package versions were provided in the input, so remediation should be validated against vendor advisories, distribution changelogs, or upstream stable kernel release notes for this patch. Where immediate patching is not possible, reduce exposure by avoiding qdisc-less/noqueue transmit paths where feasible, reviewing virtual network and veth configurations, disabling unnecessary XDP programs on affected paths, ensuring standard qdisc behavior where appropriate, and monitoring or tuning environments that frequently encounter transmit drops. These mitigations may reduce likelihood but should not be treated as a substitute for a fixed kernel.

How to confirm the fix worked

Confirm that the running kernel includes the vendor backport or upstream commit corresponding to "net: consume xmit errors of GSO frames." Use package manager metadata, kernel changelogs, distribution security advisories, or source inspection rather than relying only on the kernel version string, because vendors may backport fixes. Validate exposure by reviewing interfaces for qdisc-less/noqueue behavior using commands such as `tc qdisc show` and by checking offload/XDP-related configuration with tools such as `ip -d link show` and `ethtool -k`. Functional validation can include reproducing representative high-throughput TCP traffic over the relevant virtual or qdisc-less path and confirming that connections continue to make progress during induced drops rather than stalling indefinitely.

Typical attack path

1. Identify a Linux-hosted service or network path using affected kernel networking behavior, especially virtual interfaces, veth/container networking, XDP, disabled TSO, or qdisc-less transmit paths.
2. Establish or induce TCP traffic that is segmented using GSO/TSO-like batching before device transmission.
3. Cause or rely on transmit failures or packet drops on individual segments of a GSO frame.
4. Trigger a condition where some segments are delivered while TCP interprets the GSO transmit result as though later data was not sent.
5. Force the TCP sender and receiver into inconsistent sequence-number state.
6. Maintain or repeat the condition until affected connections stall, time out, or require reset, causing availability impact.

How to detect it

Detection is primarily behavioral because the flaw does not produce a unique default log entry. Review network and application telemetry for established TCP sessions that stop making progress, repeated retransmissions, excessive duplicate ACKs, service timeouts, or connections that remain open until reset. Useful sources include application timeout logs, load balancer health checks, host network metrics, `ss`/`netstat` snapshots, `/proc/net/snmp` TCP counters, kernel tracepoints, eBPF telemetry, packet captures, and interface drop/error counters. Focus on paths involving veth, container networking, XDP-attached interfaces, noqueue/qdisc-less devices, disabled TSO/GSO behavior, or bursts of transmit drops. In packet captures, look for repeated retransmissions from the sender while the receiver continues acknowledging sequence numbers beyond the sender's apparent progress. In kernel tracing, investigate TCP retransmission events, transmit errors from virtual devices, and ACK rejection behavior around stalled flows. No named threat actors or ransomware campaigns were provided for this vulnerability.

What your security team should do

• Prioritize patching Linux systems that host network-facing services, container platforms, virtual networking infrastructure, high-throughput TCP services, or interfaces using veth, XDP, noqueue/qdisc-less behavior, or disabled TSO paths.
• Track distribution advisories for the affected Linux kernel packages and confirm the specific fix is present, since no fixed versions were supplied.
• Inventory systems with virtual networking and qdisc-less interfaces using `tc qdisc show`, `ip -d link show`, and configuration management data.
• Add monitoring for abnormal TCP stalls, retransmission spikes, service timeouts, and long-lived connections with no forward progress.
• If patching is delayed, evaluate whether affected paths can be moved to standard qdisc handling or whether unnecessary XDP/offload-altering configurations can be removed.
• Do not treat the low EPSS score or lack of KEV listing as proof of no risk; use them to prioritize, but still remediate systems where availability is important.