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
