In the Linux kernel, the following vulnerability has been resolved:

iouring/rsrc: reject zero-length fixed buffer import

validatefixedrange() admits bufaddr at the exact end of the registered region when len is zero, because the check uses strict greater-than (bufend > imu->ubuf + imu->len). ioimportfixed() then computes offset == imu->len, which causes the bvec skip logic to advance past the last biovec entry and read bvoffset from out-of-bounds slab memory.

Return early from ioimportfixed() when len is zero. A zero-length import has no data to transfer and should not walk the bvec array at all.

BUG: KASAN: slab-out-of-bounds in ioimportregbuf+0x697/0x7f0 Read of size 4 at addr ffff888002bcc254 by task poc/103 Call Trace: ioimportregbuf+0x697/0x7f0 iowritefixed+0xd9/0x250 ioissuesqe+0xad/0x710 ioissuesqe+0x7d/0x1100 iosubmitsqes+0x86a/0x23c0 dosysiouringenter+0xa98/0x1590 Allocated by task 103: The buggy address is located 12 bytes to the right of allocated 584-byte region [ffff888002bcc000, ffff888002bcc248)

On 5/7/26 18:28, Jens Axboe wrote: I won't comment too much on this to avoid offending anyone, but I'm a bit puzzled by:

"Once we have the address of modprobepath (from KASLR step above), we write our script path via /proc/sys/kernel/modprobe: c

int fd = open("/proc/sys/kernel/modprobe", OWRONLY); write(fd, "/var/tmp/evil.sh", 16);

This sysctl entry writes directly into modprobepath in kernel memory and is writable with CAPSYSADMIN, which we already have via CAPNETADMIN on container configurations that grant both."

as surely the point of a local exploit is, in fact, to gain root in the first place. If you already have CAPSYSADMIN, what is the point?

But hey, someone wrote a blog post about something that sounds dangerous.

On Thu, May 07, 2026 at 04:28:56PM -0600, Jens Axboe wrote: On 5/7/26 11:48 AM, Solar Designer wrote: 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. I'm sorry Mohamed for just assuming you didn't communicate further; I got too used to send-and-forget kind of vulnerability reports lately. I'm pretty sure that issue was fixed by:

commit 003049b1c4fb8aabb93febb7d1e49004f6ad653b Author: Kai Aizen <kai () snailsploit com> Date: Wed Feb 18 17:36:41 2026 +0000

iouring/zcrx: fix userref race between scrub and refill paths

which is already in stable.

CC'ing in Pavel, who was inexplicably dropped from the emails, even though he is the one guy that should indeed be on the CC list. I'm at fault for dropping Pavel. The oss-security list adds Reply-To pointing to the list, which at least with Mutt replaces what's in From in reply-to-all, and I forgot to override that. I then realized, but thought (maybe wrongly) that since Pavel had replied to the thread he must be either on the list or on s@k.o anyway. Sorry, and thank you Jens for re-adding Pavel. 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 I won't comment too much on this to avoid offending anyone, but I'm a bit puzzled by:

"Once we have the address of modprobepath (from KASLR step above), we write our script path via /proc/sys/kernel/modprobe: c

int fd = open("/proc/sys/kernel/modprobe", OWRONLY); write(fd, "/var/tmp/evil.sh", 16);

This sysctl entry writes directly into modprobepath in kernel memory and is writable with CAPSYSADMIN, which we already have via CAPNETADMIN on container configurations that grant both."

as surely the point of a local exploit is, in fact, to gain root in the first place. If you already have CAPSYSADMIN, what is the point?

But hey, someone wrote a blog post about something that sounds dangerous. Oh, wow. That is indeed ridiculous, and puts everything else in this report in (greater) doubt. Not only would that require privileges to write into that sysctl, but also why determine "the address of modprobepath" if we were going to just use sysctl. The actual code in zcrxlpe.c tries to determine the address, but then does not use the address, and does not use sysctl either. So it would not do what's claimed even if run as root, as far as I can see. Note that "mp" is a local variable that's only checked for non-NULL and not passed anywhere:

uint64t mp = kallsymsaddr("modprobepath"); uint64t kt = kallsymsaddr("text"); if (mp) printf("[+] modprobepath @ 0x%lx\n", mp); else printf("[!] modprobepath unreadable (kptrrestrict)\n"); if (kt) printf("[+] text @ 0x%lx\n", kt);

timet t0 = writeevilsh(); printf("[] evil.sh written (t0=%ld)\n", t0);

if (method == 0 || method == 1) methoda(ifname); if (method == 0 || method == 2) methodb(ifname); if (method == 0 || method == 3) methodc(ifname);

printf("\n[] dmesg:\n"); system("dmesg 2>/dev/null | tail -20 | " "grep -iE 'warnon|bug:|oob|freecount|zcrx|niov|kasan|panic' " "|| echo ' (nothing)'" );

if (mp) { printf("\n[] modprobe escalation...\n"); triggermodprobe(t0); escalate(t0); }

printf("\n[] done\n"); return 0;

So AI slop it is. The question is whether there's any substance here?

Alexander

On 5/7/26 8:32 PM, Solar Designer wrote: On Thu, May 07, 2026 at 04:28:56PM -0600, Jens Axboe wrote: On 5/7/26 11:48 AM, Solar Designer wrote: 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. I'm sorry Mohamed for just assuming you didn't communicate further; I got too used to send-and-forget kind of vulnerability reports lately. I'm pretty sure that issue was fixed by:

commit 003049b1c4fb8aabb93febb7d1e49004f6ad653b Author: Kai Aizen <kai () snailsploit com> Date: Wed Feb 18 17:36:41 2026 +0000

iouring/zcrx: fix userref race between scrub and refill paths

which is already in stable.

CC'ing in Pavel, who was inexplicably dropped from the emails, even though he is the one guy that should indeed be on the CC list. I'm at fault for dropping Pavel. The oss-security list adds Reply-To pointing to the list, which at least with Mutt replaces what's in From in reply-to-all, and I forgot to override that. I then realized, but thought (maybe wrongly) that since Pavel had replied to the thread he must be either on the list or on s@k.o anyway. Sorry, and thank you Jens for re-adding Pavel. 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 I won't comment too much on this to avoid offending anyone, but I'm a bit puzzled by:

"Once we have the address of modprobepath (from KASLR step above), we write our script path via /proc/sys/kernel/modprobe: c

int fd = open("/proc/sys/kernel/modprobe", OWRONLY); write(fd, "/var/tmp/evil.sh", 16);

This sysctl entry writes directly into modprobepath in kernel memory and is writable with CAPSYSADMIN, which we already have via CAPNETADMIN on container configurations that grant both."

as surely the point of a local exploit is, in fact, to gain root in the first place. If you already have CAPSYSADMIN, what is the point?

But hey, someone wrote a blog post about something that sounds dangerous. Oh, wow. That is indeed ridiculous, and puts everything else in this report in (greater) doubt. Not only would that require privileges to write into that sysctl, but also why determine "the address of modprobepath" if we were going to just use sysctl. The actual code in zcrxlpe.c tries to determine the address, but then does not use the address, and does not use sysctl either. So it would not do what's claimed even if run as root, as far as I can see. Note that "mp" is a local variable that's only checked for non-NULL and not passed anywhere:

uint64t mp = kallsymsaddr("modprobepath"); uint64t kt = kallsymsaddr("text"); if (mp) printf("[+] modprobepath @ 0x%lx\n", mp); else printf("[!] modprobepath unreadable (kptrrestrict)\n"); if (kt) printf("[+] text @ 0x%lx\n", kt);

timet t0 = writeevilsh(); printf("[] evil.sh written (t0=%ld)\n", t0);

if (method == 0 || method == 1) methoda(ifname); if (method == 0 || method == 2) methodb(ifname); if (method == 0 || method == 3) methodc(ifname);

printf("\n[] dmesg:\n"); system("dmesg 2>/dev/null | tail -20 | " "grep -iE 'warnon|bug:|oob|freecount|zcrx|niov|kasan|panic' " "|| echo ' (nothing)'" );

if (mp) { printf("\n[] modprobe escalation...\n"); triggermodprobe(t0); escalate(t0); }

printf("\n[] done\n"); return 0;

So AI slop it is. The question is whether there's any substance here? As far as I can tell, none. There was a real bug which I referenced higher up, fixed by 003049b1c4fb8aabb93febb7d1e49004f6ad653b. Which is from 3 months ago and is in -stable. Flagging some WARNONONCE() sanity check thing as any kind of real fix is, indeed, nonsense and just shows what kind of real thought went into this.

-- Jens Axboe