In the Linux kernel, the following vulnerability has been resolved: veth: reduce XDP nodirect return section to fix race As explain in commit fa349e396e48 ("veth: Fix race with AFXDP exposing old or uninitialized descriptors") for veth there is a chance after napicompletedone() that another CPU can manage start another NAPI instance running vethpool(). For NAPI this is correctly handled as the napischeduleprep() check will prevent multiple instances from getting scheduled, but for the remaining code in vethpool() this can run concurrent with the newly started NAPI instance. The problem/race is that xdpclearreturnframenodirect() isn't designed to be nested. Prior to commit 401cb7dae813 ("net: Reference bpfredirectinfo via taskstruct on PREEMPTRT.") the temporary BPF net context bpfredirectinfo was stored per CPU, where this wasn't an issue. Since this commit the BPF context is stored in 'current' taskstruct. When running veth in threaded-NAPI mode, then the kthread becomes the storage area. Now a race exists between two concurrent vethpool() 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 xdpsetreturnframenodirect() section before exiting vethpool() calls the clear-function xdpclearreturnframenodirect().