[PATCH] io_uring/net: don't truncate the bundle segment length to int

[Baul Lee <baul.lee@xbow.com>]

io_bundle_nbufs() works out how many buffers a short bundle transfer
consumed by walking the mapped iovec and subtracting each segment from the
transferred length:

	do {
		int this_len = min_t(int, iov[nbufs].iov_len, ret);

		nbufs++;
		ret -= this_len;
	} while (ret);

iov_len is a size_t while this_len is an int, so a segment longer than
INT_MAX comes out negative.  ret then grows instead of shrinking and the
loop keeps walking, reading past the end of the array it was handed.

The recv bundle path can hand it such a segment.  io_recv_buf_select()
folds sr->mshot_total_len into arg.max_len, and that field is unsigned and
taken straight from sqe->optlen:

	if (sr->flags & IORING_RECV_MSHOT_LIM)
		arg.max_len = min_not_zero(arg.max_len, sr->mshot_total_len);

With sqe->len left at 0 nothing else lowers it, so arg.max_len can be
0xffffffff.  io_ring_buffers_peek() clamps each buffer against that rather
than against INT_MAX and records an iov_len above INT_MAX; a short receive
over that bundle then enters the loop above.

An unprivileged multishot IORING_OP_RECV with IOSQE_BUFFER_SELECT and
IORING_RECVSEND_BUNDLE, a provided buffer ring registered with
IOU_PBUF_RING_INC holding two buffers, and two bytes of data is enough to
reach it.  The two-entry iovec is a 32-byte kmalloc:

  BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x114/0x1a8
  Read of size 8 at addr ffff0000d39a1b68 by task io_repro/165
  Call trace:
   io_bundle_nbufs+0x114/0x1a8
   io_recv_finish+0x138/0xa38
   io_recv+0x38c/0x1008
   io_issue_sqe+0xc4/0x155c
   io_submit_sqes+0x6d0/0x1fac
   __arm64_sys_io_uring_enter+0x30c/0x1180

  Allocated by task 165:
   __kmalloc_noprof+0x1b8/0x444
   io_ring_buffers_peek+0x57c/0xbb4
   io_buffers_peek+0x168/0x2a0
   io_recv+0x598/0x1008

  The buggy address is located 8 bytes to the right of
  allocated 32-byte region [ffff0000d39a1b40, ffff0000d39a1b60)

Count in size_t.  ret is positive by the time the loop runs, since the
function returns early for ret <= 0, so widening loses nothing; this_len
stays bounded by ret, and the mapped length is never less than ret, so the
walk ends inside the array.

Fixing it here rather than by capping arg.max_len keeps the accounting
correct for every caller and does not disturb buffer selection: an
arg.max_len of 0 is a distinct "not set yet" state that
io_ring_buffers_peek() tests before it applies its own INT_MAX default,
and pre-filling it changes which bundles get expanded.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Fixes: a05d1f625c7a ("io_uring/net: support bundles for send")
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
---
The sr->len path into this loop is already rejected in
io_{send,recv}msg_prep(); this one comes in through sqe->optlen instead,
which is unsigned and so never trips a negative-length check.

 io_uring/net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/net.c b/io_uring/net.c
index 00a7df803b99..e8a066f8a9e3 100644
--- a/io_uring/net.c
+++ b/io_uring/net.c
@@ -500,7 +500,7 @@ static int io_bundle_nbufs(struct io_async_msghdr *kmsg, int ret)
 	/* short transfer, count segments */
 	nbufs = 0;
 	do {
-		int this_len = min_t(int, iov[nbufs].iov_len, ret);
+		size_t this_len = min_t(size_t, iov[nbufs].iov_len, ret);
 
 		nbufs++;
 		ret -= this_len;
-- 
2.53.0