GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-PP8F-5MJ5-QP78

Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-27 06:31
VLAI
Details

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

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-74742"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-26T15:16:52Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nveth: fix queue index used to wake the peer txq in veth_poll\n\nveth_poll() derives the index of the peer TX queue to wake from\nrq-\u003exdp_rxq.queue_index. That field is only initialized by\nxdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an\nXDP program is attached. On the plain GRO/NAPI path\n(veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so\nqueue_index stays 0 for every queue, as priv-\u003erq is zero-allocated.\n\nSo in a multi-queue setup with GRO enabled and no XDP program attached,\nevery NAPI instance looks at the peer\u0027s TX queue 0. If veth_xmit() stops\npeer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing\never wakes it again: the poller draining queue 1 wakes queue 0 instead.\nveth implements no ndo_tx_timeout, so the netdev watchdog does not kick\nin either, and the queue stays stopped indefinitely.\n\nDerive the index from the position of the rq within priv-\u003erq instead,\nwhich is correct regardless of whether XDP was ever enabled.\n\nScripts to reproduce the stall are available at\nhttps://github.com/netoptimizer/veth-backpressure-performance-testing",
  "id": "GHSA-pp8f-5mj5-qp78",
  "modified": "2026-08-27T06:31:30Z",
  "published": "2026-08-27T06:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74742"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/60db47f02bfa2aa688938aa199117ec4f8e31d23"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73f8dd22b1e533a99ecc3f9b5de6c6daccaecace"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/90bb11fb29d3c55a2c46dc7c386d096b286e7fcf"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b662a1fb4f3a5ea19bac24eea8315b1d05be51e7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…