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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-28T08:16:45.303Z",
  "pubdate": "2026-08-28T08:16:45.303Z",
  "executiveSummary": "This vulnerability is a Use-After-Free (UAF) flaw residing in the Linux kernel veth driver's XDP enablement error handling path.\nThe issue stems from an improper cleanup sequence during failed XDP queue registrations, specifically involving the leak of an unreferenced napi_struct within the device's NAPI list.\nImpact includes potential kernel memory corruption, system instability, and possible local privilege escalation or arbitrary code execution.\nThe vulnerability affects systems utilizing veth interfaces configured with XDP, where an error during the queue registration process leaves a dangling pointer in the kernel's NAPI management structures.\nExploitation requires a local attacker to trigger the error condition during XDP enablement, followed by the destruction and reallocation of the veth device's underlying memory structures.\nThis is a high-risk kernel-level vulnerability that necessitates patching the specific error-handling rollback logic to ensure all initialized resources are properly deallocated before memory is returned to the allocator.",
  "technicalDetails": "The root cause of this vulnerability is an off-by-one logic error within the error rollback loop of the veth driver's XDP enablement routine. When xdp_rxq_info_reg() or xdp_rxq_info_reg_mem_model() fails, the driver attempts to revert previously configured RX queues. The rollback loop decrements the loop index 'i' prematurely, failing to invoke netif_napi_del() for the NAPI structure associated with the queue that triggered the failure.\nBecause netif_napi_add() was successfully executed for index 'i' prior to the registration failure, the corresponding napi_struct remains linked in the device's napi_list. The premature decrement in the rollback loop causes the driver to skip the essential netif_napi_del() call for this specific index.\nThe attack flow proceeds as follows: First, an attacker initiates an XDP enablement sequence on a veth interface designed to trigger a registration failure at a specific queue index. Second, due to the flawed rollback, the kernel retains a reference to the dangling napi_struct within the device structure's internal NAPI list. Third, the attacker initiates the teardown or destruction of the veth interface, causing the kernel to free the memory block that originally housed the queue data and the leaked napi_struct.\nPost-free, the kernel's slab allocator may reallocate this memory region for other kernel objects. When the device teardown process eventually iterates through the NAPI list to perform cleanup, it encounters the dangling pointer. Because the memory has been reallocated and repurposed, the iteration logic performs operations on the now-alien memory, leading to heap corruption.\nThe exploitation of this flaw can result in a Use-After-Free scenario where the attacker influences the content of the reallocated memory, potentially allowing for control-flow hijacking or the leakage of sensitive kernel data. The vulnerability is restricted to local execution, as it requires the ability to trigger interface configuration changes. Privilege requirements typically involve CAP_NET_ADMIN or root-level access to the network namespace, limiting the scope to locally authenticated users or container environments with elevated networking capabilities."
}