[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADPKJ-4HUKdt8jgsVWoecBc9qOZQ_4wXkSW8kas9mXVyWt9a+w@mail.gmail.com>
Date: Mon, 26 Jan 2026 09:57:57 +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月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.
This is not an AI hallucination, and it can be demonstrated by a userspace PoC.
Powered by blists - more mailing lists