[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a62d1b48-9e5f-4dca-bd34-dc86fbd97344@gmail.com>
Date: Fri, 8 May 2026 03:04:15 +0100
From: Pavel Begunkov <asml.silence@...il.com>
To: Jens Axboe <axboe@...nel.dk>, Solar Designer <solar@...nwall.com>,
oss-security@...ts.openwall.com
Cc: Mohamed salem Eddah <medsalemeddah@...il.com>, security@...nel.org
Subject: Re: CVE request: io_uring zcrx freelist OOB write
On 5/7/26 23:28, Jens Axboe wrote:
> 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
To be fair, he did reply, but I didn't notice that he dropped
all CC.
>> 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@...ilsploit.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.
Not even that, the reproducer couldn't ever work. I asked David
to run it to humour it with predictable results as well. I'm sure
Mohamed has never run any of that.
> 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.
Urgh, I'm better to avoid commenting on that.
>> 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
That looks like AI hallucination, I'd rather save my time
instead of taking it apart point by point. It seems like the
blog came from the same person, and, Mohamed, publishing a full
disclosure for something you think is a real issue before the
investigation has concluded is a sure way to piss people off.
> 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.
but at least it's better than "step 1: insert a broken module" as
it was in the original submission :)
--
Pavel Begunkov
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.
