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: <79ae8fdf-460d-439a-977b-6876c808bb75@kernel.dk>
Date: Mon, 26 Jan 2026 05:36:27 -0700
From: Jens Axboe <axboe@...nel.dk>
To: clingfei <clf700383@...il.com>
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

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.

> 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