diff options
author | Jann Horn <jannh@google.com> | 2024-12-18 19:56:25 +0300 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2024-12-19 04:19:33 +0300 |
commit | 12d908116f7efd34f255a482b9afc729d7a5fb78 (patch) | |
tree | 0d51d751857400bca11ed4bc72150642d0675b21 /rust/kernel/workqueue.rs | |
parent | 020b40f3562495f3c703a283ece145ffec19e82d (diff) | |
download | linux-12d908116f7efd34f255a482b9afc729d7a5fb78.tar.xz |
io_uring: Fix registered ring file refcount leak
Currently, io_uring_unreg_ringfd() (which cleans up registered rings) is
only called on exit, but __io_uring_free (which frees the tctx in which the
registered ring pointers are stored) is also called on execve (via
begin_new_exec -> io_uring_task_cancel -> __io_uring_cancel ->
io_uring_cancel_generic -> __io_uring_free).
This means: A process going through execve while having registered rings
will leak references to the rings' `struct file`.
Fix it by zapping registered rings on execve(). This is implemented by
moving the io_uring_unreg_ringfd() from io_uring_files_cancel() into its
callee __io_uring_cancel(), which is called from io_uring_task_cancel() on
execve.
This could probably be exploited *on 32-bit kernels* by leaking 2^32
references to the same ring, because the file refcount is stored in a
pointer-sized field and get_file() doesn't have protection against
refcount overflow, just a WARN_ONCE(); but on 64-bit it should have no
impact beyond a memory leak.
Cc: stable@vger.kernel.org
Fixes: e7a6c00dc77a ("io_uring: add support for registering ring file descriptors")
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://lore.kernel.org/r/20241218-uring-reg-ring-cleanup-v1-1-8f63e999045b@google.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'rust/kernel/workqueue.rs')
0 files changed, 0 insertions, 0 deletions