io_msg_remote_post() sets up dangling pointer (but it is never accessed)?

io_msg_remote_post() sets up dangling pointer (but it is never accessed)?

[Jann Horn]

Hi!

I think the following statement in io_msg_remote_post():

req->tctx = READ_ONCE(ctx->submitter_task->io_uring);

sets req->tctx to a pointer that may immediately become dangling if
the ctx->submitter_task concurrently goes through execve() including
the call path:

begin_new_exec -> io_uring_task_cancel -> __io_uring_cancel(true) ->
io_uring_cancel_generic(true, ...) -> __io_uring_free()

However, I can't find any codepath that can actually dereference the
req->tctx of such a ring message; and I did some quick test under
KASAN, and that also did not reveal any issue.

I think the current code is probably fine, but it would be nice if we
could avoid having a potentially dangling pointer here. Can we NULL
out the req->tctx in io_msg_remote_post(), or is that actually used
for some pointer comparison or such?

Re: io_msg_remote_post() sets up dangling pointer (but it is never accessed)?

[Jann Horn]

On Wed, Jan 22, 2025 at 12:41 AM Jann Horn <jannh@google.com> wrote:
> I think the following statement in io_msg_remote_post():
>
> req->tctx = READ_ONCE(ctx->submitter_task->io_uring);
>
> sets req->tctx to a pointer that may immediately become dangling if
> the ctx->submitter_task concurrently goes through execve() including
> the call path:
>
> begin_new_exec -> io_uring_task_cancel -> __io_uring_cancel(true) ->
> io_uring_cancel_generic(true, ...) -> __io_uring_free()
>
> However, I can't find any codepath that can actually dereference the
> req->tctx of such a ring message; and I did some quick test under
> KASAN, and that also did not reveal any issue.
>
> I think the current code is probably fine, but it would be nice if we
> could avoid having a potentially dangling pointer here. Can we NULL
> out the req->tctx in io_msg_remote_post(), or is that actually used
> for some pointer comparison or such?

This seems to have been the case since commit
b6f58a3f4aa8dba424356c7a69388a81f4459300 ("io_uring: move struct
io_kiocb from task_struct to io_uring_task").

Re: io_msg_remote_post() sets up dangling pointer (but it is never accessed)?

[Jens Axboe]

On 1/21/25 4:41 PM, Jann Horn wrote:
> Hi!
> 
> I think the following statement in io_msg_remote_post():
> 
> req->tctx = READ_ONCE(ctx->submitter_task->io_uring);
> 
> sets req->tctx to a pointer that may immediately become dangling if
> the ctx->submitter_task concurrently goes through execve() including
> the call path:
> 
> begin_new_exec -> io_uring_task_cancel -> __io_uring_cancel(true) ->
> io_uring_cancel_generic(true, ...) -> __io_uring_free()
> 
> However, I can't find any codepath that can actually dereference the
> req->tctx of such a ring message; and I did some quick test under
> KASAN, and that also did not reveal any issue.
> 
> I think the current code is probably fine, but it would be nice if we
> could avoid having a potentially dangling pointer here. Can we NULL
> out the req->tctx in io_msg_remote_post(), or is that actually used
> for some pointer comparison or such?

Yep that should just go away, I'll send out a patch.

-- 
Jens Axboe