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, 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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T15:16:52.990Z",
  "pubdate": "2026-08-26T15:16:52.990Z",
  "executiveSummary": "A logical flaw exists in the Linux kernel veth (Virtual Ethernet) driver involving improper identification of peer transmit queues during NAPI polling.\nThe vulnerability occurs in multi-queue configurations when XDP is disabled, leading to a permanent stall of peer transmit queues.\nImpact includes a denial-of-service condition for the affected virtual interface, as packets queued for transmission on specific rings may be permanently blocked.\nThe vulnerability affects Linux kernel systems utilizing veth interfaces with multi-queue support and GRO (Generic Receive Offload) enabled, even without XDP configuration.\nAn attacker capable of generating sufficient traffic to trigger flow control (NETDEV_TX_BUSY) on a veth interface can effectively disable the interface's transmit capability for specific queues.\nNo authentication or specific privileges are required to trigger this state if the attacker can influence the traffic load on the affected interface.",
  "technicalDetails": "The root cause of the vulnerability lies in the incorrect derivation of the peer TX queue index within the veth_poll() function. The driver erroneously relies on rq->xdp_rxq.queue_index to identify the corresponding peer transmit queue to be woken after processing.\nThe xdp_rxq_info_reg() function, which populates the queue_index field, is only executed during veth_enable_xdp_range(). Consequently, in standard GRO/NAPI paths where XDP is not initialized, the queue_index remains at the default zeroed value from the memory allocation of priv->rq.\nIn a multi-queue environment without XDP, every NAPI instance incorrectly maps its peer wakeup signal to the peer's TX queue 0. This creates a race condition and a logical deadlock: if veth_xmit() encounters a full ptr_ring on a non-zero TX queue (e.g., TX queue 1) and returns NETDEV_TX_BUSY, the flow control state stops that specific queue.\nWhen the NAPI poller subsequently drains packets from the corresponding receive queue, it attempts to wake the peer via veth_poll(). Due to the faulty index derivation, it only triggers a wakeup on TX queue 0, leaving TX queue 1 in a permanently stopped state.\nSince veth does not implement ndo_tx_timeout to trigger a watchdog reset of stalled queues, the interface remains unable to process traffic on the affected queue indefinitely, resulting in a persistent Denial of Service for that specific transmission path.\nThe exploitation flow involves: 1) Establishing a multi-queue veth configuration. 2) Ensuring no XDP program is attached. 3) Generating high-volume traffic patterns that induce backpressure on the peer ptr_ring. 4) Observing the cessation of transmission on the target queue due to the failure of the wake-up logic to target the correct index.\nThe fix involves refactoring the index derivation to use the memory position of the rq structure within the priv->rq array, which provides an accurate index regardless of the XDP configuration state."
}