CVE-2026-74742

Technical Description

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

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

veth_poll() derives the index of the peer TX queue to wake from

rq->xdp_rxq.queue_index. That field is only initialized by

xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an

XDP program is attached. On the plain GRO/NAPI path

(veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so

queue_index 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 veth_xmit() stops

peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing

ever wakes it again: the poller draining queue 1 wakes queue 0 instead.

veth implements no ndo_tx_timeout, 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,

whic

Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

References