ZeroHour

CVE-2026-80613

mass

Linux kernel veth driver: NAPI leak in XDP error path leads to use-after-free

CVSS 3.1
7.8 high
EPSS
<1%p3
Published
()
Modified
AI analysis

CVE-2026-80613 is a flaw in the Linux kernel's veth virtual network driver: when enabling XDP on a veth device fails at the receive-queue registration step, the error-path rollback skips deleting the NAPI polling structure for the failed queue, leaving a dangling napi_struct on the device's NAPI list. The bug is triggered when a veth device that hit this XDP-registration failure is later destroyed: the freed queue memory can be reused, and teardown then walks the stale NAPI entry and corrupts the reallocated memory, causing a use-after-free. An attacker able to create and destroy veth devices with XDP enabled — typically a local user or container workload with network administration rights — gains kernel memory corruption that can crash the host and potentially achieve local privilege escalation, consistent with the high local CVSS score. All kernels containing the vulnerable veth code are technically affected, but only configurations that actually enable XDP on veth (e.g., some container networking setups and XDP testing) can reach the faulty path. No public proof-of-concept or in-the-wild exploitation is known; EPSS estimates a roughly 0.1% probability of exploitation in the next 30 days and the flaw is not in CISA KEV.

What to do: Update the Linux kernel to a release or vendor build that includes the upstream fix commit 'veth: fix NAPI leak in XDP enable error path' and verify the fix appears in your distribution's changelog. Until patched, avoid enabling XDP on veth devices or reconfiguring/destroying veth devices with XDP enabled, and audit whether your workloads or CNI plugins use XDP over veth.

Affected
Linux kernel — veth virtual Ethernet driver (drivers/net/veth)
Estimated exposure
massmillions of Linux hosts carry the vulnerable veth code (veth pairs are default container/network-namespace plumbing), though only a much smaller subset —… — veth devices are created for nearly every container or network namespace under Docker/Kubernetes and the driver is built into mainstream distribution kernels, but the buggy path is only reachable when XDP is actually enabled on a veth…

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

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 xdp_rxq_info_reg() or xdp_rxq_info_reg_mem_model() 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 netif_napi_deli() for rq[i].xdp_napi. Since netif_napi_add() was already called for index 'i', this leaves a dangling napi_struct in the device's napi_list. 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.

Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.