CVE-2026-74742

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix queue index used to wake the peer txq in veth_poll<br /> <br /> veth_poll() derives the index of the peer TX queue to wake from<br /> rq-&gt;xdp_rxq.queue_index. That field is only initialized by<br /> xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an<br /> XDP program is attached. On the plain GRO/NAPI path<br /> (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so<br /> queue_index stays 0 for every queue, as priv-&gt;rq is zero-allocated.<br /> <br /> So in a multi-queue setup with GRO enabled and no XDP program attached,<br /> every NAPI instance looks at the peer&amp;#39;s TX queue 0. If veth_xmit() stops<br /> peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing<br /> ever wakes it again: the poller draining queue 1 wakes queue 0 instead.<br /> veth implements no ndo_tx_timeout, so the netdev watchdog does not kick<br /> in either, and the queue stays stopped indefinitely.<br /> <br /> Derive the index from the position of the rq within priv-&gt;rq instead,<br /> which is correct regardless of whether XDP was ever enabled.<br /> <br /> Scripts to reproduce the stall are available at<br /> https://github.com/netoptimizer/veth-backpressure-performance-testing