|
|
Message-ID: <CAN+TWHTGkGZu4vdbkMY8F-EDe3m8ScBctW-fdtfcpGbj192SyA@mail.gmail.com> Date: Wed, 27 May 2026 23:53:45 +0100 From: Prénom? Ahmed <ahmedabdelmoumen05@...il.com> To: oss-security@...ts.openwall.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, security@...nel.org Subject: Linux: DMA-after-unmap race in ZCRX via netif_rxq_cleanup_unlease() ordering inversion (netkit + page_pool) Hello, I would like to report a source-proven teardown ordering bug in the Linux kernel that can lead to a DMA-after-unmap race condition involving ZCRX (io_uring zero-copy receive), page_pool, and netkit queue leasing. ***Reporter:** Ahmed Abdelmoemen **Discovery Date:** 2026-05-26 **Kernel Version:** Linux 7.1.0-rc3* Executive Summary *A logic error in `netif_rxq_cleanup_unlease()` causes DMA mappings for the ZCRX memory provider to be revoked **before** the physical NIC RX queue is stopped. This creates a race window during netkit queue lease teardown where the physical device's NAPI can consume stale `net_iov` entries from the page_pool alloc cache containing `dma_addr = 0`.* The ordering inversion is fully proven at the source level. However, I have **not** performed runtime verification, so actual memory corruption or successful DMA to address 0 has **not** been proven — it remains hardware and driver dependent. The bug is reachable with `CAP_NET_ADMIN` (common in container environments) when using netkit with ZCRX. Root Cause In `net/core/netdev_rx_queue.c:347-348`: ```c __netif_mp_uninstall_rxq(virt_rxq, p); // DMA unmap + dma_addr=0 __netif_mp_close_rxq(...); // queue stop + NAPI disable (TOO LATE) This inverts the correct ordering used in normal device unregistration and io_uring close paths (stop first, then unmap). Impact - *Potential:* NIC DMA write to physical address 0 (or stale mappings with lazy IOMMU) leading to memory corruption. - *Requirements:* CAP_NET_ADMIN + netkit queue leasing + ZCRX installed on the leased queue. - *Current Status:* No runtime PoC or crash reproduction yet. The race window exists in theory but its practical exploitability needs confirmation. I am attaching the full detailed analysis. Proposed Fix[image: image.png] I am happy to provide more details or assist with testing. Best regards, Ahmed Abdelmoemen ahmedabdelmoumen05@...il.com Content of type "text/html" skipped Download attachment "image.png" of type "image/png" (74833 bytes) View attachment "zcrx_teardown_race_audit.md" of type "text/markdown" (47070 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.