Re: [SECURITY] io_uring UAF: io_uring_cmd_issue_blocking missing sqe copy before RESIZE_RINGS

[Jens Axboe <axboe@kernel.dk>]

On 5/4/26 5:59 AM, Carlo Conti wrote:
> Hello,
> 
> I have identified a Use-After-Free vulnerability in the Linux kernel
> io_uring subsystem, confirmed on Linux 6.19.11.
> 
> The primary finding is the UAF itself, both a read and a write
> primitive have been confirmed experimentally. As a secondary research
> step, I also attempted to build a privilege escalation chain on top of
> these primitives. The LPE reaches root but with a structural
> limitation described below; I am reporting it in this state because
> the UAF primitives are reliable and independently exploitable, and I
> believe the escalation path warrants further investigation by the
> kernel team.  
> 
> --- ROOT CAUSE ---
> 
> io_uring_cmd_issue_blocking() in fs/io_uring.c calls

fs/io_uring.c hasn't been a thing in many years?

> io_req_queue_iowq(req) without first calling io_req_sqe_copy(). As a
> result, the ioucmd->sqe field continues to point to the original
> sq_sqes buffer.
> 
> If IORING_REGISTER_RESIZE_RINGS (opcode 33) is issued immediately
> after, io_free_region() frees the old sq_sqes page. When the io-wq
> worker is eventually scheduled, it reads sqe->ioprio and other fields
> from the freed page ? Use-After-Free read.
> 
> Additional issue: io_free_region() does not call zap_vma_ptes() for
> single-page non-vmap regions, so the userspace mmap of the old sq_sqes
> (IORING_OFF_SQES) remains mapped to the freed physical page, providing
> an arbitrary write primitive ? Use-After-Free write.

Can you expand? Seems unrelated and also unlikely to be an issue, unless
it's missing something explicitly.
> 
> --- PRIMITIVES ---
> 
> UAF read:  confirmed. ioprio=0xFFFF written to live page before RESIZE;
>            worker reads it from freed page ? blkdev_uring_cmd() returns
>            -EINVAL. CQE ud=0x2222 res=-22 observed.
> 
> UAF write: confirmed. Arbitrary write to freed page via stale PTE,
>            verified with sentinel probe (new mmap of IORING_OFF_SQES
>            does not see the sentinel written via the old mmap).
> 
> --- LPE STATUS ---
> 
> Cross-cache struct cred overwrite is blocked by a refcount invariant:
> vm_insert_pages() increments page refcount 1?2 at mmap time;
> io_free_region()'s release_pages() decrements 2?1 (not to 0). The page
> remains KPF_MMAP=1, KPF_BUDDY=0 while the stale mmap is open, so
> cred_jar cannot allocate it. Closing the mmap frees the page but
> eliminates the write primitive (fundamental mutual exclusion).
> 
> A fully unprivileged LPE would require a second independent write
> primitive or a different victim object. Current PoC achieves root via
> a research-context SUID binary to demonstrate the primitive chain.

> 
> --- REPRODUCTION ---
> 
> Requirements:
>   modprobe null_blk queue_mode=2 submit_queues=1 home_node=0     completion_nsec=500000000 queue_depth=1 discard=1 size=1024
>   chmod a+rw /dev/nullb0

So... you need to be root in the first place here?

Since a) you need to be root, and b) you sent this to both the public
list and the security list, why don't you just send a patch for this?

Taking security@ off the CC.

-- 
Jens Axboe