Re: [PATCH] io_uring: gate personality per opcode to fix TOCTOU check in io_msg_ring_prep

[Jens Axboe <axboe@kernel.dk>]

On 1/25/26 6:57 PM, clingfei wrote:
> Jens Axboe <axboe@kernel.dk> ?2026?1?25??? 22:16???
>>
>> On 1/25/26 12:53 AM, clingfei wrote:
>>> From: Cheng Lingfei <clf700383@gmail.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