The Linux kernel contains a bug in the veth_poll() routine that selects the peer transmit queue index from rq->xdp_rxq.queue_index. This field is only initialized when an XDP program is attached, but remains zero on the normal NAPI path. In a multi‑queue configuration with Generic Receive Offload enabled and no XDP program attached, the poller always targets queue 0. When another queue reaches NETDEV_TX_BUSY, it never wakes, and the stalled queue stays paused forever because the driver lacks a tx timeout handler. The result is a local denial of service where traffic on a vulnerable veth pair stalls indefinitely.

Every Linux kernel that supports veth virtual Ethernet devices with multiple transmit queues is affected as long as Generic Receive Offload (GRO) is enabled on those interfaces and no XDP program is attached. The vulnerability is a kernel‑level flaw and thus applies to all distributions that ship the affected kernel code, regardless of vendor.

The attack requires local access to a veth pair or the ability to generate traffic that triggers the head‑of‑line stall. There is no remote exploitation vector or path to arbitrary code execution. The EPSS score is not provided and the vulnerability is not listed in the CISA KEV catalog. The impact is a high‑grade denial of service for network traffic on the affected interfaces. The risk is moderate to high for environments where local privileged users can attach or configure veth devices with multiple queues and GRO enabled.