CVE-2026-74742: veth: fix queue index used to wake the peer txq in veth_poll
In the Linux kernel, the following vulnerability has been resolved:
veth: fix queue index used to wake the peer txq in vethpoll
vethpoll() derives the index of the peer TX queue to wake from rq->xdprxq.queueindex. That field is only initialized by xdprxqinforeg() in vethenablexdprange(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (vethnapienablerange()) xdprxqinforeg() is never called, so queueindex stays 0 for every queue, as priv->rq is zero-allocated.
So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If vethxmit() stops peer TX queue 1 because the ptrring is full (NETDEVTXBUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndotxtimeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely.
Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled.
Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the queue stall?
The affected path requires a multi-queue veth setup with GRO enabled and no XDP program attached. Under those conditions, all NAPI instances can use peer TX queue 0 when attempting to wake a stopped peer queue.
What event causes traffic to become stuck?
A peer TX queue other than queue 0 must be stopped after its ptr_ring becomes full and veth_xmit() returns NETDEV_TX_BUSY. When the corresponding poller drains that queue, it wakes queue 0 instead of the stopped queue, leaving the stopped queue indefinitely unavailable.
Will the kernel watchdog recover the stalled queue?
No. veth has no ndo_tx_timeout implementation, so the netdev watchdog does not recover the stopped queue described here.
How can administrators determine whether a system matches the affected condition?
Check whether veth interfaces use multiple queues with GRO enabled while no XDP program is attached. The issue manifests when a nonzero peer TX queue is stopped due to a full ptr_ring and remains stopped after that queue is drained.