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

GHSA-68W5-72RC-PGRC

Vulnerability from github – Published: 2025-12-23 15:30 – Updated: 2026-07-30 06:32
VLAI
Details

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

veth: reduce XDP no_direct return section to fix race

As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing old or uninitialized descriptors") for veth there is a chance after napi_complete_done() that another CPU can manage start another NAPI instance running veth_pool(). For NAPI this is correctly handled as the napi_schedule_prep() check will prevent multiple instances from getting scheduled, but for the remaining code in veth_pool() this can run concurrent with the newly started NAPI instance.

The problem/race is that xdp_clear_return_frame_no_direct() isn't designed to be nested.

Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") the temporary BPF net context bpf_redirect_info was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' task_struct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent veth_pool() function calls one exiting NAPI and one running new NAPI, both using the same BPF net context.

Race is when another CPU gets within the xdp_set_return_frame_no_direct() section before exiting veth_pool() calls the clear-function xdp_clear_return_frame_no_direct().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-68341"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-23T14:16:40Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nveth: reduce XDP no_direct return section to fix race\n\nAs explain in commit fa349e396e48 (\"veth: Fix race with AF_XDP exposing\nold or uninitialized descriptors\") for veth there is a chance after\nnapi_complete_done() that another CPU can manage start another NAPI\ninstance running veth_pool(). For NAPI this is correctly handled as the\nnapi_schedule_prep() check will prevent multiple instances from getting\nscheduled, but for the remaining code in veth_pool() this can run\nconcurrent with the newly started NAPI instance.\n\nThe problem/race is that xdp_clear_return_frame_no_direct() isn\u0027t\ndesigned to be nested.\n\nPrior to commit 401cb7dae813 (\"net: Reference bpf_redirect_info via\ntask_struct on PREEMPT_RT.\") the temporary BPF net context\nbpf_redirect_info was stored per CPU, where this wasn\u0027t an issue. Since\nthis commit the BPF context is stored in \u0027current\u0027 task_struct. When\nrunning veth in threaded-NAPI mode, then the kthread becomes the storage\narea. Now a race exists between two concurrent veth_pool() function calls\none exiting NAPI and one running new NAPI, both using the same BPF net\ncontext.\n\nRace is when another CPU gets within the xdp_set_return_frame_no_direct()\nsection before exiting veth_pool() calls the clear-function\nxdp_clear_return_frame_no_direct().",
  "id": "GHSA-68w5-72rc-pgrc",
  "modified": "2026-07-30T06:32:25Z",
  "published": "2025-12-23T15:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68341"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a14602fcae17a3f1cb8a8521bedf31728f9e7e39"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c1ceabcb347d1b0f7e70a7384ec7eff3847b7628"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d0bd018ad72a8a598ae709588934135017f8af52"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/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…