CVE-2026-74742: Linux Kernel veth Driver DOS Vulnerability

CVE-2026-74742 Overview

CVE-2026-74742 is a Linux kernel vulnerability in the virtual Ethernet (veth) driver. The flaw resides in veth_poll(), which derives the peer transmit queue index from rq->xdp_rxq.queue_index. That field is only initialized when an eXpress Data Path (XDP) program is attached. On the plain Generic Receive Offload (GRO)/NAPI path, the index remains zero for every queue in a multi-queue configuration. When a peer TX queue other than queue 0 stops due to a full ptr_ring, the poller wakes queue 0 instead, leaving the actual stopped queue stalled indefinitely. The veth driver implements no ndo_tx_timeout, so the netdev watchdog does not recover the condition.

Critical Impact
Multi-queue veth interfaces with GRO enabled and no XDP program attached can experience indefinite TX queue stalls, causing denial of service for container and virtualization workloads relying on veth pairs.

Affected Products

Linux kernel veth driver on the GRO/NAPI receive path
Multi-queue veth configurations without an attached XDP program
Container and virtualization environments using veth pairs (Kubernetes, Docker, LXC, systemd-nspawn)

Discovery Timeline

2026-08-26 - CVE-2026-74742 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-74742

Vulnerability Analysis

The veth driver provides paired virtual Ethernet interfaces used extensively in Linux container networking. Each peer maintains RX queues, and the NAPI poller for one side is responsible for waking the corresponding TX queue on the other side when packets are drained from the shared ptr_ring.

The defect is a queue-index mismatch inside veth_poll(). The function reads rq->xdp_rxq.queue_index to identify which peer TX queue to wake. That structure is only populated by xdp_rxq_info_reg() inside veth_enable_xdp_range(), which executes only when an XDP program attaches to the interface. On the standard GRO/NAPI path invoked through veth_napi_enable_range(), xdp_rxq_info_reg() is never called. Because priv->rq is zero-allocated, every queue reports queue_index = 0.

The result is a persistent traffic stall. When veth_xmit() returns NETDEV_TX_BUSY and stops peer TX queue N (for N > 0), the poller draining that queue instead wakes queue 0. The stopped queue never resumes, and no watchdog exists to reset it. This is an availability-impact denial of service condition on the Linux kernel network path.

Root Cause

The root cause is an initialization dependency between two code paths. The queue index metadata inside xdp_rxq_info is treated as authoritative by veth_poll(), but its initialization is gated behind XDP program attachment. Non-XDP configurations leave the field at its zero-initialized default, producing incorrect wakeup targets in multi-queue setups.

Attack Vector

A local or co-located workload that generates sufficient TX pressure on a peer veth queue can trigger the ptr_ring full condition and induce the stall. In multi-tenant container hosts, a noisy neighbor generating burst traffic through a shared veth pair can indefinitely disable one or more transmit queues, degrading or halting network connectivity for co-located containers. No authentication or user interaction is required beyond the ability to send traffic.

The fix derives the queue index from the position of the receive queue within priv->rq, which is correct regardless of whether XDP was ever enabled. Reproduction scripts are published in the veth-backpressure-performance-testing repository.

Detection Methods for CVE-2026-74742

Indicators of Compromise

Persistent TX queue stall on veth interfaces observable via ip -s -s link show showing rising dropped or stagnant tx_packets counters on specific queues.
Container network throughput collapse without corresponding CPU saturation, especially on hosts running multi-queue veth pairs without XDP.
Absence of watchdog reset events for veth devices despite obvious traffic backpressure.

Detection Strategies

Query /proc/net/dev and per-queue statistics under /sys/class/net/<veth>/queues/tx-*/ to identify individual queues with zero forward progress under load.
Correlate NETDEV_TX_BUSY return conditions with sustained queue stop states using bpftrace or ftrace on netif_tx_stop_queue and netif_tx_wake_queue.
Inspect running kernel versions across the fleet and flag hosts running unpatched veth code paths where multi-queue GRO is in use.

Monitoring Recommendations

Alert on unexpected drops in container-to-container throughput on hosts using veth interfaces with multiple queues.
Baseline per-queue TX counters and alert when a subset of queues stops advancing while others continue.
Track kernel patch levels through configuration management and centralize the data in a security data lake for fleet-wide visibility.

How to Mitigate CVE-2026-74742

Immediate Actions Required

Identify hosts running affected kernels with multi-queue veth configurations and prioritize them for patching.
Apply the upstream veth fix that derives the peer TX queue index from the position of rq within priv->rq.
Restart or re-create veth pairs after applying the kernel update to clear any queues currently stuck in the stopped state.

Patch Information

The fix is available in the following upstream commits: 60db47f, 73f8dd2, 90bb11f, and b662a1f. Consume the fix through your distribution's stable kernel updates.

Workarounds

Reduce veth interfaces to a single queue (ethtool -L <veth> combined 1) until the kernel patch is applied, eliminating the multi-queue mismatch.
Attach a minimal pass-through XDP program to affected veth interfaces so that xdp_rxq_info_reg() initializes queue_index correctly.
Lower per-queue TX burst rates from tenant workloads to reduce the likelihood of ptr_ring saturation and the resulting NETDEV_TX_BUSY condition.

bash

# Temporary workaround: collapse veth to a single queue
ethtool -L veth0 combined 1
ethtool -L veth1 combined 1

# Verify current queue configuration
ethtool -l veth0