CVE-2026-74742

In the Linux kernel, the following vulnerability has been resolved:

veth: fix queue index used to wake the peer txq in veth_poll

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