io_msg_remote_post() sets up dangling pointer (but it is never accessed)?
From: Jann Horn
Date: Tue Jan 21 2025 - 18:42:10 EST
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?