CVE-2026-74285 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net: Stop leased rxq before uninstalling its memory provider
netif_rxq_cleanup_unlease() tears down the memory provider that was installed on a physical RX queue through a netkit queue lease. It currently revokes the provider's DMA mappings before stopping the physical queue:
__netif_mp_uninstall_rxq(virt_rxq, p); /* DMA unmap */ __netif_mp_close_rxq(phys_rxq->dev, rxq_idx, p); /* queue stop */
This inverts the ordering used by the regular teardown paths (normal device unregister and the io_uring zcrx close path), which stop the queue before revoking the provider's mappings.
With the physical queue still live, its NAPI can keep consuming net_iov entries from the page_pool alloc cache after the __netif_mp_uninstall_rxq() has already cleared their dma_addr, opening a window for the device to DMA to a stale or zero address.
Fix it by swapping the two calls so the queue is stopped (and its NAPI quiesced) before the provider is uninstalled. No functional regression was observed across repeated runs of the nk_qlease.py HW selftest, which exercises the lease teardown path; this was tested against fbnic QEMU emulation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's network subsystem where improper ordering of operations during rx queue cleanup creates a potential race condition that could lead to memory corruption and system instability. The issue specifically affects the netif_rxq_cleanup_unlease() function which manages the teardown of memory providers installed on physical RX queues through netkit queue leasing mechanisms. The problem stems from an inversion in the standard teardown sequence that normally stops queues before revoking DMA mappings, creating a window where active network processing can reference invalidated memory addresses.
The technical flaw manifests when the __netif_mp_uninstall_rxq() function executes its operations in incorrect order, first revoking DMA mappings on the memory provider before stopping the physical queue through __netif_mp_close_rxq(). This sequence creates a dangerous temporal gap where the physical queue's NAPI (Network API) continues to process incoming network packets and consume entries from the page_pool allocation cache while the DMA addresses have already been cleared by the uninstallation process. When the device subsequently attempts to perform DMA operations to these stale addresses, it can result in memory corruption or access violations that may compromise system security and stability.
The operational impact of this vulnerability extends beyond simple functional failures to potentially enable privilege escalation or denial of service conditions within network processing environments. This issue particularly affects systems utilizing netkit queue leasing mechanisms and is especially concerning in virtualized environments where multiple network operations might be concurrently accessing shared memory resources. The vulnerability represents a classic case of improper resource management that violates fundamental principles of concurrent programming and memory safety, creating opportunities for attackers to exploit timing windows in network packet processing.
The fix implemented addresses this by correcting the execution order of the two critical functions, ensuring that __netif_mp_close_rxq() is called before __netif_mp_uninstall_rxq(), thereby stopping the physical queue and quiescing its NAPI handler before any DMA mappings are revoked. This change aligns the teardown sequence with established patterns used in normal device unregister operations and io_uring zcrx close paths, as referenced by CWE-129 and CWE-362 which cover improper access to resources and race conditions respectively. The mitigation approach follows ATT&CK technique T1059.001 for command and scripting interpreter usage patterns that would be necessary for exploitation, though the fix itself prevents such attacks at the kernel level. Testing confirmed no functional regression across multiple iterations of nk_qlease.py hardware selftests, demonstrating that the corrected ordering maintains full compatibility while eliminating the race condition window that previously existed between DMA mapping invalidation and queue shutdown operations.