Follow @Openwall on Twitter for new release announcements and other news
[<prev] [day] [month] [year] [list]
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.