linux-kernel - Re: [PATCH] io_uring: gate personality per opcode to fix TOCTOU check in io_msg_ring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADPKJ-42_AXtjyaEmbDdkw2D_CXRgJ5U=Z1yc505V2f0YSS0xg@mail.gmail.com>
Date: Tue, 27 Jan 2026 10:24:40 +0800
From: clingfei <clf700383@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] io_uring: gate personality per opcode to fix TOCTOU check
 in io_msg_ring_prep

Jens Axboe <axboe@...nel.dk> 于2026年1月26日周一 20:36写道：
>
> On 1/25/26 6:57 PM, clingfei wrote:
> > Jens Axboe <axboe@...nel.dk> ?2026?1?25??? 22:16???
> >>
> >> On 1/25/26 12:53 AM, clingfei wrote:
> >>> From: Cheng Lingfei <clf700383@...il.com>
> >>>
> >>> Add allow_personality io_issue_def and reject personality use in
> >>> io_init_req for opcodes that do not permit it. This fixes a TOCTOU
> >>> window in the prior implementation: userspace could race-update
> >>> sqe->personality and bypass the __io_msg_ring_prep personality check.
> >>
> >> Please do detail what the bug is here, this looks like some kind of
> >> AI hallucination. The check in msg_ring prep exists just to reject
> >> commands with it set, for future expansion. The only thing that
> >> matters is the ordering and use in io_init_req(), which is fine.
> >>
> >> --
> >> Jens Axboe
> >>
> > Sorry, I forgot to reply to all in the previous email.
> >
> > The io_init_req checks sqe->personality; if personality is not zero,
> > req->creds is initialized based on personality. The msg_ring prep also checks
> > sqe->personality and rejects non-zero personality values. However, sqe is
> > shared between the kernel and userspace. This means a user can submit a
> > msg_ring SQE with a non-zero personality. After passing the check in
> > io_init_req, the user process can concurrently modify personality to
> > set it to 0,
> > thus enabling it to pass the check in msg_ring prep and invalidating
> > its rejection
> > of non-zero `personality` values.
>
> I'm not disputing you can't change ->personality between io_init_req()
> and __io_msg_ring_prep(), that's obviously possible. I'm saying that it
> doesn't matter one bit at all, as the check in __io_msg_ring_prep() is
> just there for future proofing. If the application knowingly changes the
> SQE post submit to defeat an -EINVAL return, then yes it'll defeat the
> future proofing. But so what? If you look at other prep handlers, the
> -EINVAL checks never made any attempts at protecting against this
> scenario, as it's only there for future proofing.
>
> IOW, you could just remove this check in __io_msg_ring_prep() and it'd
> be fine. Or just leave it alone, because it really doesn't serve a
> purpose.
>
Thanks for your patient reply.

I agree that this does not matter since it cannot be leveraged for
further exploitation.
Initially, I read the Linux 6.6 version of the code, which can only
affect fpl->user
in __io_scm_file_account when the cred is substituted with another process's.
However, I found that this portion has been removed in the latest
kernel version...

By the way, I did read other prep handlers’ code, but almost none included
a similar double-check that could be bypassed in the same manner, which is
why I find this a bit strange.

> > This is not an AI hallucination, and it can be demonstrated by a
> > userspace PoC.
>
> It does read like one, however... Including this reply.
>
> --
> Jens Axboe