summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorChris Mason <mason@kernel.org>2026-10-21 08:24:13 +0000
committerJens Axboe <axboe@kernel.dk>2026-10-28 10:50:07 -0600
commit8543a39f03db8816a2d80d0c92c132a19f2afb48 (patch)
tree97594a9134a0f90a53cfefe52428ea412b3627ae /tools/lib/python
parent51bab09b7ca1a9a6dd9303a3b7ee346f8128c963 (diff)
io_uring/bpf-ops: clear bpf_ctx while submitting SQEs
bpf_io_uring_submit_sqes() calls io_submit_sqes() from inside the loop program, with current->bpf_ctx set, and requests issued inline run with it set too. The socket code uses has_current_bpf_ctx() to recognize calls from bpf_setsockopt() and friends, where the caller holds the socket lock and has already been vetted, and skips both. So a SOCKET_URING_OP_SETSOCKOPT from the SQ passes sockopt_capable() without the capability, and runs without lock_sock(). A task with no capability can set SO_MARK, IP_TRANSPARENT or TCP_REPAIR, and two threads changing IP_OPTIONS on one socket, one through the ring, double free in no time. SOCK_DESTROY via IORING_OP_SENDMSG ends up in tcp_abort() without the lock the same way. Clear the run context around io_submit_sqes(). The SQEs come from userspace and must be issued like those of any other ring. They still run inside the program's RCU tasks trace read section, so a request that sleeps there holds up that grace period, but other request types do that already. Fixes: 890819248a86 ("io_uring/bpf-ops: add kfunc helpers") Signed-off-by: Chris Mason <mason@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions