CVE-2026-80613 in Linux
Summary
by MITRE • 08/28/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/28/2026
This vulnerability represents a critical use-after-free condition within the Linux kernel's virtual Ethernet driver implementation, specifically affecting the XDP enablement error path. The root cause lies in an incorrect rollback mechanism when initializing network queue pairs for eXpress Data Path operations. During the setup process, the driver iterates through queues to register receive queue information using functions such as xdp_rxq_info_reg or xdp_rxq_info_reg_mem_model. If one of these registration calls fails, the system attempts to undo any successfully completed registrations by iterating backwards from the current index down to a starting point. The logic intended to skip unregistering resources for the failed index is flawed because it decrements the loop counter before checking conditions, which inadvertently causes the loop body to execute without processing the NAPI structure associated with that specific failed queue.
The technical flaw centers on the omission of netif_napi_del calls during this rollback sequence. While the driver correctly avoids unregistering RX queues for indices where registration did not complete or was already cleaned up, it fails to remove the corresponding napi_struct entries from the device's internal NAPI list. Since netif_napi_add had previously been invoked for these interfaces, a dangling pointer remains in memory even though the underlying queue resources are being released. This creates a state inconsistency where the kernel believes certain NAPI structures are still active and attached to the network interface, while their backing memory is marked for release or has already been freed during subsequent cleanup operations.
The operational impact of this vulnerability is severe, leading directly to use-after-free exploitation scenarios. When the virtual Ethernet device is eventually destroyed, the kernel iterates over its NAPI list to perform teardown procedures. Because the leaked napi_struct entries were never removed, the iteration process attempts to access memory that has already been freed or reallocated for other purposes. This results in heap corruption and potential arbitrary code execution if an attacker can control the contents of the reused memory region. The vulnerability affects system stability and security by allowing local privilege escalation or denial of service through kernel panic conditions triggered by malformed device teardown sequences.
Mitigation strategies primarily involve applying upstream Linux kernel patches that correct the loop logic to explicitly call netif_napi_del for any index where registration failed before proceeding with further rollback operations. System administrators should ensure their kernels are updated to versions containing this fix, particularly those running virtualized environments or containers utilizing veth interfaces with XDP capabilities enabled. From a defensive perspective, monitoring for unusual kernel oops messages related to NAPI list corruption can help detect exploitation attempts in real-time. Additionally, enforcing strict network namespace isolation limits the blast radius should an attacker successfully leverage this flaw within a containerized workload.
This issue aligns with CWE-416, which describes use-after-free vulnerabilities resulting from improper resource management during error handling paths. In terms of attack classification under MITRE ATT&CK for Enterprise or ICS, it falls under Taint Shared Components and potentially influences Defense Evasion if used to bypass security controls by crashing protective mechanisms like kernel lockdown modes. The vulnerability highlights the importance of rigorous code review practices in low-level driver development, particularly when managing complex state transitions during initialization failures where multiple resources must be atomically rolled back without leaving orphaned pointers or structures behind.