Strobes VIStrobes VI
CVE DatabaseThreat ActorsResearchAdvisoryAPI Docs
Visit Strobes.coSign Up for Strobes
CVE DatabaseThreat ActorsResearchAdvisoryAPI Docs
Tools
KB Lookup
Visit Strobes.coSign Up for Strobes
HomeCVEs

Do you like the insights?

Strobes vulnerability intelligence is a key component of their Exposure Management platform that helps organizations understand, prioritize, and address security vulnerabilities more effectively.

© 2026 Strobes Security. All rights reserved.
HomeCVEsCVE-2025-68341

CVE-2025-68341

Published: February 3, 2026
Last updated:6 hours ago (February 3, 2026)
Exploit: NoZero-day: NoPatch: YesTrend: Neutral
TL;DR
Updated February 3, 2026

CVE-2025-68341 is a low severity vulnerability with a CVSS score of 0.0. No known exploits currently, and patches are available.

Key Points
  • 1Low severity (CVSS 0.0/10)
  • 2No known public exploits
  • 3Vendor patches are available
Severity Scores
CVSS v30.0
CVSS v20.0
Priority Score0.0
EPSS Score0.0
None
Exploitation LikelihoodMinimal
0.00%EPSS

Very low probability of exploitation

Monitor and patch as resources allow
0.00%
EPSS
0.0
CVSS
No
Exploit
Yes
Patch
Low Priority
no major risk factors

EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.

Description

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().

CVSS v3 Breakdown
Attack Vector:-
Attack Complexity:-
Privileges Required:-
User Interaction:-
Scope:-
Confidentiality:-
Integrity:-
Availability:-
Trend Analysis
Neutral
Advisories
GitHub AdvisoryNVD
Cite This Page
APA Format
Strobes VI. (2026). CVE-2025-68341 - CVE Details and Analysis. Strobes VI. Retrieved February 3, 2026, from https://vi.strobes.co/cve/CVE-2025-68341
Quick copy link + title

Please cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.