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

A flaw of LOW impact was found in the Linux kernel veth (virtual Ethernet) driver. When a veth device is used with XDP in threaded-NAPI mode, code in veth_poll() that executes after napi_complete_done() can run concurrently with a newly started NAPI instance on the same kthread. Because the BPF redirect context (bpf_redirect_info) is stored in the kthread's task_struct, two overlapping veth_poll() invocations can both manipulate the xdp_set_return_frame_no_direct()/xdp_clear_return_frame_no_direct() section, which is not designed to be nested. This can leave the XDP return-frame state stale or incorrect and potentially crash the kernel, so the impact is limited to availability. Triggering the race requires local access with the ability to configure veth devices and run XDP on them (typically CAP_NET_ADMIN), and it is most relevant when threaded NAPI is enabled; Red Hat therefore scores this flaw CVSS 3.1 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), which differs substantially from the upstream CVE.org score of 9.8 that assumes a network-based, unauthenticated attack vector that is not supported by the technical evidence. The vulnerable code is not present in Red Hat Enterprise Linux 7, 8, or 9, or in Red Hat In-Vehicle OS 1.0, so those products are not affected; Red Hat Enterprise Linux 6 is out of support scope. The Red Hat Enterprise Linux 10 kernel streams are affected; given the low impact of this flaw, the fix for those streams has been deferred, leaving a residual risk of a local denial of service in environments that run XDP on veth devices in threaded-NAPI mode.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

The race is only reachable when XDP programs run on veth devices operating in threaded-NAPI mode. As a workaround, avoid that configuration: do not attach XDP programs to veth devices, or do not enable threaded NAPI on veth devices where XDP programs are used. No updated kernel packages containing the fix are available for the affected Red Hat Enterprise Linux 10 streams at this time because the fix has been deferred.