CVE-2026-80613: veth: fix NAPI leak in XDP enable error path
In the Linux kernel, the following vulnerability has been resolved:
veth: fix NAPI leak in XDP enable error path
During XDP enablement in veth, if xdprxqinforeg() or xdprxqinforegmemmodel() fails, the driver rolls back the changes.
However, the rollback loop: for (i--; i >= start; i--) {
decrements the loop index 'i' before the first iteration. This correctly skips unregistering the rxq for the failed index 'i' (as registration failed or was already cleaned up), but it also erroneously skips calling netifnapideli() for rq[i].xdpnapi.
Since netifnapiadd() was already called for index 'i', this leaves a dangling napistruct in the device's napilist. When the veth device is later destroyed, the freed queue memory (which contains the leaked NAPI structure) can be reused.
The subsequent device teardown iterates the NAPI list and corrupts the reallocated memory, leading to UAF.
Fix this by explicitly deleting the NAPI association for the failed index 'i' before rolling back the successfully configured queues.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the use-after-free?
XDP enablement on a veth device must enter an error path because xdp_rxq_info_reg() or xdp_rxq_info_reg_mem_model() fails. The affected veth device must then later be destroyed, causing teardown to traverse a NAPI list containing a dangling entry.
What happens if the vulnerable error path is reached?
The failed XDP setup leaves a napi_struct associated with the veth device after its queue memory is freed. If that memory is reallocated before device teardown, iteration of the stale NAPI entry can corrupt the reallocated memory and lead to a use-after-free.
Is normal successful XDP enablement affected?
The described issue is specifically in rollback after XDP enablement fails during receive-queue registration or memory-model registration. The provided information does not indicate that a successful XDP enablement path triggers the leak.