aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/call-graph-from-sql.py
diff options
context:
space:
mode:
authorJann Horn <[email protected]>2024-12-18 17:56:25 +0100
committerJens Axboe <[email protected]>2024-12-18 18:19:33 -0700
commit12d908116f7efd34f255a482b9afc729d7a5fb78 (patch)
tree0d51d751857400bca11ed4bc72150642d0675b21 /tools/perf/scripts/python/call-graph-from-sql.py
parent020b40f3562495f3c703a283ece145ffec19e82d (diff)
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: [email protected] Fixes: e7a6c00dc77a ("io_uring: add support for registering ring file descriptors") Signed-off-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-sql.py')
0 files changed, 0 insertions, 0 deletions