Alexander, Pavel,

First, an apology: I replied to Pavel's questions directly without CC'ing oss-security. That was a mistake. Putting the reply on the list now.

To Pavel's question yes, triggered. whitout involving a kernel modules

Kernel: 6.19.11+kali-amd64, built April 9 2026, pre-770594e Hardware: mlx5 ConnectX-6 (real ZCRX NIC) Trigger: pure userspace via SIOCSIFFLAGS IFFDOWN, CAPNETADMIN

The OOB fires during pagepooldestroy() when two paths both push to the same freelist without a bounds check:

path A — ptrring drain: ioppzcreleasenetmem() per queued niov → freecount++

path B — ioppzcdestroy() scrub: for each niov with urefarray[i] != 0: iozcrxreturnniov() → freecount++ (no bounds check)

Niovs that land in both paths push freecount past numniovs. The write at freelist[numniovs] goes 4 bytes past the end of the kcalloc'd array into the adjacent slab object.

Disassembly from the live kernel via gdb+/proc/kcore confirms no bounds check at either write site:

asm ; iozcrxreturnniov (pp==NULL / freelist path) 0xffffffffa7016890: mov eax, [rdx+0x44] ; eax = freecount 0xffffffffa7016893: mov r8, [rdx+0x48] ; r8 = freelist ptr 0xffffffffa7016897: lea edi, [rax+1] 0xffffffffa701689a: mov [rdx+0x44], edi ; freecount++ (unconditional) 0xffffffffa70168fb: mov [r8+rax4], edi ; freelist[oldcount] = niovidx ; OOB when rax == numniovs

; ioppzcreleasenetmem (ptrring drain callback) 0xffffffffa701795f: mov eax, [rbp+0x44] ; eax = freecount 0xffffffffa7017962: mov rdx, [rbp+0x48] ; rdx = freelist ptr 0xffffffffa701796a: lea ecx, [rax+1] 0xffffffffa701796d: mov [rbp+0x44], ecx ; freecount++ 0xffffffffa701797b: mov [rdx+rax4], ebx ; freelist[oldcount] = niovidx

770594e adds WARNONONCE(freecount >= numniovs) + early return at both sites. The OOB write is suppressed. The double-count condition still occurs the second push is silently dropped.

The fix is not in any stable branch. Distributions shipping 6.15+ kernels with CONFIGIOURINGZCRX=y before April 21 are affected.

To Alexander's point on originality: I am not claiming to have found the bug before 770594e was merged. My contribution is the documented trigger path from pure userspace, the disassembly confirming the write sites, and the stable backport request. The fix exists upstream but has not reached any stable queue. That gap is what this report is about.

The blog post at ze3tar.github.io is mine.

Three open questions for Pavel if you have a moment:

1. Is the NIC-down path (SIOCSIFFLAGS -> pagepooldestroy) the scrub case you referred to in the original thread?

2. Does 770594e fully resolve the issue or is a follow-up planned to prevent the double-count at the source rather than at the write?

3. Does IORINGREGISTERZCRXIFQ check capable() or nscapable()? The latter would widen the attack surface on distributions with permissive user namespace policy

Backport request for 770594e to 6.15.y stands.

-- Mohamed

On Thu, May 7, 2026 at 1:48 PM Solar Designer <solar () openwall com> wrote: On Mon, May 04, 2026 at 07:02:30AM +0100, Pavel Begunkov wrote: On 5/3/26 12:00, Mohamed salem Eddah wrote: I am reporting a security issue in the Linux kernel involving an out-of-bounds heap write in iouring/zcrx.c.

This issue appears to have been addressed in commit 770594e (“iouring/zcrx: warn on freelist violations”, April 21, 2026), however it was not assigned a CVE and does not appear to have been included in a formal security advisory. As a result, multiple stable and downstream distribution kernels are still affected. ------------------------------ Vulnerability Summary

File: iouring/zcrx.c Function: iozcrxreturnniovfreelist() Introduced: Linux 6.12 (initial ZCRX merge) FWIW, it was added IIRC in 6.15, but not 6.12 Fixed upstream: 770594e (Apr 21, 2026) Status: Fix not yet present in stable releases Did you trigger the problem or the warning in a new kernel without the attached modules? Which kernel version / hash was it? There was a fix for the scrub case, but otherwise don't immediately see how that can happen. I'll take a look. I only skimmed, but as far as I can tell Mohamed isn't the original finder of this issue and the report and PoCs are AI-generated, which could be why Mohamed is not communicating further. It's becoming a trend - someone sends AI-generated report and doesn't communicate. Which doesn't mean the report is useless, but it does complicate its handling.

Meanwhile, it looks like there's a blog post (by someone else? I am confused) on exploitation of this issue, with exploit files attached:

https://ze3tar.github.io/post-zcrx.html

Alexander