Re: CVE request: io_uring zcrx freelist OOB write

[Jens Axboe <axboe () kernel dk>]

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
> >
> >     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.
>
> 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 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.
>
> 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
> modprobe_path" if we were going to just use sysctl.  The actual code in
> zcrx_lpe.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:
>
>     uint64_t mp = kallsyms_addr("modprobe_path");
>     uint64_t kt = kallsyms_addr("_text");
>     if (mp) printf("[+] modprobe_path @ 0x%lx\n", mp);
>     else    printf("[!] modprobe_path unreadable (kptr_restrict)\n");
>     if (kt) printf("[+] _text @ 0x%lx\n", kt);
>
>     time_t t0 = write_evil_sh();
>     printf("[*] evil.sh written (t0=%ld)\n", t0);
>
>     if (method == 0 || method == 1) method_a(ifname);
>     if (method == 0 || method == 2) method_b(ifname);
>     if (method == 0 || method == 3) method_c(ifname);
>
>     printf("\n[*] dmesg:\n");
>     system("dmesg 2>/dev/null | tail -20 | "
>            "grep -iE 'warn_on|bug:|oob|free_count|zcrx|niov|kasan|panic' "
>            "|| echo '    (nothing)'" );
>
>     if (mp) {
>         printf("\n[*] modprobe escalation...\n");
>         trigger_modprobe(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 WARN_ON_ONCE()
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