CVE-2025-68341
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 o...
Affects 1 product across 3 vendors.
A race condition in the Linux kernel's veth driver could potentially allow an attacker to access old or uninitialized descriptors, which could lead to information disclosure or other unspecified impacts.
BSID: BS-2025-GLOBAL-030037-I • Model: /workspace/models/qwen2.5-coder-32b-instruct-bf16 • Confidence: MEDIUM
Is this CVE in your environment?
BreachSpider monitors your ICS/OT environment for vulnerabilities like this one. No agents or network access required. Free to start.
Check My Environment →What is CVE-2025-68341?
What is the CVSS score for CVE-2025-68341?
Is CVE-2025-68341 actively exploited?
How do I remediate CVE-2025-68341?
What systems are affected by CVE-2025-68341?
| CVE ID | CVE-2025-68341 |
|---|---|
| BSID | BS-2025-GLOBAL-030037-I BreachSpider Global ID |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Published | 2025-12-23 |
| Last Modified | 2026-10-19 |
| ICS Relevance | 0% |
| Source | NVD |
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().
Source: NIST NVD / MITRE CVE Database
The vulnerability arises from a race condition in the veth driver's handling of XDP (eXpress Data Path) no_direct return section. After napi_complete_done(), another CPU might start a new NAPI instance running veth_pool(), which could lead to the exposure of old or uninitialized descriptors.
Exploitation Likelihood: MEDIUM
No official vendor advisory link on record. See the CVE record →
| CISA known-exploited | Not in KEV catalog |
|---|---|
| Public Exploit | Not confirmed |
| PoC Code | Not confirmed |
AI Enrichment Record — provenance & audit hash
| Model | /workspace/models/qwen2.5-coder-32b-instruct-bf16 |
|---|---|
| Confidence | MEDIUM |
| Enriched At | 2026-05-24 |
| SHA-512 Audit Hash | 9874137e549673897163628766f8320c302510989e9c8c9bfb353075d337ed267518a317d58f3282c527b6c5e0094441db0e77681d8050f96600f8f95e5464bb |
Critical Severity - Know Your Exposure
A CVSS 9.8 vulnerability in your ICS environment cannot wait. BreachSpider maps critical CVEs to your specific assets and tells you what to fix first.
Create a free account →