Re: CVE request: io_uring zcrx freelist OOB write

[Jens Axboe <axboe () kernel dk>]

On 5/7/26 11:48 AM, Solar Designer 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 io_uring/zcrx.c.
> > >
> > > This issue appears to have been addressed in commit 770594e
> > > (?io_uring/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:* io_uring/zcrx.c
> > > *Function:* io_zcrx_return_niov_freelist()
> > > *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.

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

    io_uring/zcrx: fix user_ref 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.

> 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 modprobe_path (from KASLR step above), we
write our script path via /proc/sys/kernel/modprobe: c

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

This sysctl entry writes directly into modprobe_path in kernel memory
and is writable with CAP_SYS_ADMIN, which we already have via
CAP_NET_ADMIN 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 CAP_SYS_ADMIN, what is the point?

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

-- 
Jens Axboe