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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <14b994e8-1e14-407c-afe9-5ed87dfc6abb@kernel.dk>
Date: Wed, 22 Jan 2025 16:56:34 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Jann Horn <jannh@...gle.com>
Cc: io-uring <io-uring@...r.kernel.org>,
 kernel list <linux-kernel@...r.kernel.org>
Subject: Re: io_msg_remote_post() sets up dangling pointer (but it is never
 accessed)?

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