[PATCH] io_uring/kbuf: fix use-after-free of new iovec on bundle grow

[PATCH] io_uring/kbuf: fix use-after-free of new iovec on bundle grow

[Breno Leitao]

When io_ring_buffers_peek() grows a provided-buffer bundle, it allocates
a new iovec array and points arg->iovs at it. The KBUF_MODE_FREE cleanup
added at the end of the function then does kfree(arg->iovs), which frees
this freshly allocated array that is about to be returned to and used by
the caller, instead of the old cached iovec (org_iovs) it was meant to
release. The caller reads the now-freed array, resulting in a
use-after-free, easily triggered by the liburing recv-bundle-short-ooo
test:

  BUG: KASAN: slab-use-after-free in io_recv+0x4bc/0xc60
  Read of size 8 at addr ffff00037b20c240 by task recv-bundle-sho
   io_recv
  Allocated by task:
   __kmalloc_noprof
   io_ring_buffers_peek
   io_buffers_peek
   io_recv
  Freed by task:
   kfree
   io_ring_buffers_peek
   io_buffers_peek
   io_recv

Free org_iovs instead, and only when it was actually replaced by a new
allocation. On the access_ok() failure path the new array is already
freed and the request is left pointing at the original iovec, so nothing
needs to be released at this point in that case.

Fixes: cd053d788c3f ("io_uring: fix dangling iovec after provided-buffer bundle grow failure")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 io_uring/kbuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/io_uring/kbuf.c b/io_uring/kbuf.c
index b6b969b55e122..07d81dc7cbe29 100644
--- a/io_uring/kbuf.c
+++ b/io_uring/kbuf.c
@@ -328,8 +328,8 @@ static int io_ring_buffers_peek(struct io_kiocb *req, struct buf_sel_arg *arg,
 		buf = io_ring_head_to_buf(br, ++head, bl->mask);
 	} while (--nr_iovs);
 
-	if (arg->mode & KBUF_MODE_FREE)
-		kfree(arg->iovs);
+	if ((arg->mode & KBUF_MODE_FREE) && arg->iovs != org_iovs)
+		kfree(org_iovs);
 
 	if (head == tail)
 		req->flags |= REQ_F_BL_EMPTY;

---
base-commit: bee763d5f341b99cf472afeb508d4988f62a6ca1
change-id: 20260713-io_uring_dangling-87c23d568135

Best regards,
--  
Breno Leitao <leitao@debian.org>

Re: [PATCH] io_uring/kbuf: fix use-after-free of new iovec on bundle grow

[Gabriel Krisman Bertazi]

Breno Leitao <leitao@debian.org> writes:

> When io_ring_buffers_peek() grows a provided-buffer bundle, it allocates
> a new iovec array and points arg->iovs at it. The KBUF_MODE_FREE cleanup
> added at the end of the function then does kfree(arg->iovs), which frees
> this freshly allocated array that is about to be returned to and used by
> the caller, instead of the old cached iovec (org_iovs) it was meant to
> release. The caller reads the now-freed array, resulting in a
> use-after-free, easily triggered by the liburing recv-bundle-short-ooo
> test:
>
>   BUG: KASAN: slab-use-after-free in io_recv+0x4bc/0xc60
>   Read of size 8 at addr ffff00037b20c240 by task recv-bundle-sho
>    io_recv
>   Allocated by task:
>    __kmalloc_noprof
>    io_ring_buffers_peek
>    io_buffers_peek
>    io_recv
>   Freed by task:
>    kfree
>    io_ring_buffers_peek
>    io_buffers_peek
>    io_recv
>
> Free org_iovs instead, and only when it was actually replaced by a new
> allocation. On the access_ok() failure path the new array is already
> freed and the request is left pointing at the original iovec, so nothing
> needs to be released at this point in that case.
>
> Fixes: cd053d788c3f ("io_uring: fix dangling iovec after provided-buffer bundle grow failure")
> Signed-off-by: Breno Leitao <leitao@debian.org>

Already fixed here

https://lore.kernel.org/io-uring/20260712142612.188695595-iostreampy@proton.me/T/#u

here:

https://lore.kernel.org/io-uring/OS3PR01MB8810F38D613E37FBD684DC4D83FB2@OS3PR01MB8810.jpnprd01.prod.outlook.com/T/#t

and here:

https://lore.kernel.org/io-uring/20260713183124.4217-1-doruk@0sec.ai/T/#u

Aren't LLMs fun?

-- 
Gabriel Krisman Bertazi

Re: [PATCH] io_uring/kbuf: fix use-after-free of new iovec on bundle grow

[Breno Leitao]

On Tue, Jul 14, 2026 at 10:01:28AM -0400, Gabriel Krisman Bertazi wrote:
> Breno Leitao <leitao@debian.org> writes:
> 
> > When io_ring_buffers_peek() grows a provided-buffer bundle, it allocates
> > a new iovec array and points arg->iovs at it. The KBUF_MODE_FREE cleanup
> > added at the end of the function then does kfree(arg->iovs), which frees
> > this freshly allocated array that is about to be returned to and used by
> > the caller, instead of the old cached iovec (org_iovs) it was meant to
> > release. The caller reads the now-freed array, resulting in a
> > use-after-free, easily triggered by the liburing recv-bundle-short-ooo
> > test:
> >
> >   BUG: KASAN: slab-use-after-free in io_recv+0x4bc/0xc60
> >   Read of size 8 at addr ffff00037b20c240 by task recv-bundle-sho
> >    io_recv
> >   Allocated by task:
> >    __kmalloc_noprof
> >    io_ring_buffers_peek
> >    io_buffers_peek
> >    io_recv
> >   Freed by task:
> >    kfree
> >    io_ring_buffers_peek
> >    io_buffers_peek
> >    io_recv
> >
> > Free org_iovs instead, and only when it was actually replaced by a new
> > allocation. On the access_ok() failure path the new array is already
> > freed and the request is left pointing at the original iovec, so nothing
> > needs to be released at this point in that case.
> >
> > Fixes: cd053d788c3f ("io_uring: fix dangling iovec after provided-buffer bundle grow failure")
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> Already fixed here
> 
> https://lore.kernel.org/io-uring/20260712142612.188695595-iostreampy@proton.me/T/#u
> 
> here:
> 
> https://lore.kernel.org/io-uring/OS3PR01MB8810F38D613E37FBD684DC4D83FB2@OS3PR01MB8810.jpnprd01.prod.outlook.com/T/#t
> 
> and here:
> 
> https://lore.kernel.org/io-uring/20260713183124.4217-1-doruk@0sec.ai/T/#u

Oh, -ETOOMANY fixes.

> Aren't LLMs fun?

Oh yes, It is easier to send the fix than to check in the mailing list
if someone has fixed it already.