Linux Kernel veth CVE-2026-74742

Exploitation requires all of the following non-default conditions to be simultaneously true: (1) a multi-queue veth interface pair must be configured (num_queues > 1, non-default for most single-container deployments); (2) GRO/NAPI must be enabled on the veth interface (the default NAPI path, but explicitly distinguishable from the XDP path); (3) no XDP program must be attached to the veth device (attaching any XDP program, even a trivial pass-through, corrects the queue_index initialization and eliminates the bug); (4) the attacker must be able to generate sufficient traffic to fill the ptr_ring of a non-zero TX queue (NETDEV_TX_BUSY). Exploitation is further limited by the requirement that the veth pair be in use - idle interfaces with no traffic cannot trigger the stall. Single-queue veth configurations are entirely unaffected. Authentication requirements are not confirmed from the provided CVSS data alone given the network-vector context.

The provided CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, score 7.5) rates this as high severity with a network attack vector and no authentication required, which warrants scrutiny. The actual triggering mechanism involves a ptr_ring saturation event on a veth TX queue - achievable by flooding traffic through a veth pair - making AV:N defensible in containerized environments where veth is exposed to network ingress, but the effective blast radius is scoped to that specific veth pair rather than the broader host. The real-world risk is meaningful for container-heavy infrastructure: a stalled veth TX queue disrupts traffic for any workload relying on that interface, and the absence of ndo_tx_timeout means the stall is permanent until the interface is manually bounced or the kernel is restarted. EPSS data is absent from the provided intelligence; KEV status is not listed, meaning active exploitation is not confirmed by CISA. No CVE-specific exploit code is known, though the reporter has published reproduction scripts. The vulnerability requires a non-default multi-queue veth configuration with GRO enabled and no XDP program, narrowing the affected population. The CWE classification is absent from the data - the root cause maps most closely to CWE-908 (Use of Uninitialized Resource). Patch commits are available across stable trees, and fixed versions are identified, making this a straightforward patch-and-verify remediation for most operators.

An attacker with the ability to inject high-volume traffic into a containerized workload's network namespace floods a multi-queue veth interface pair, saturating the ptr_ring on a non-zero TX queue and triggering NETDEV_TX_BUSY. Because veth_poll() wakes queue 0 instead of the stalled queue, all subsequent traffic on that queue is silently dropped indefinitely. The affected container loses network connectivity without generating kernel alerts or watchdog resets, enabling a persistent denial-of-service against the workload with no automatic recovery. Reproduction scripts are publicly available from the reporter at https://github.com/netoptimizer/veth-backpressure-performance-testing.