io_uring/rsrc: validate buffer count with offset for cloning

In the Linux kernel, the following vulnerability has been resolved:

io_uring/rsrc: validate buffer count with offset for cloning

syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt

that's too big:

WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024

Modules linked in:

CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT

Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)

pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024

lr : __do_kmalloc_node mm/slub.c:-1 [inline]

lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012

sp : ffff80009cfd7a90

x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0

x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000

x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8

x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff

x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005

x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000

x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938

x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000

x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000

x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001

Call trace:

__kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)

kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]

io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]

io_clone_buffers io_uring/rsrc.c:1178 [inline]

io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287

__io_uring_register io_uring/register.c:815 [inline]

__do_sys_io_uring_register io_uring/register.c:926 [inline]

__se_sys_io_uring_register io_uring/register.c:903 [inline]

__arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903

__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]

invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49

el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132

do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151

el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767

el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786

el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

which is due to offset + buffer_count being too large. The registration

code checks only the total count of buffers, but given that the indexing

is an array, it should also check offset + count. That can't exceed

IORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond

that limit.

There's no issue with registrering a table this large, outside of the

fact that it's pointless to register buffers that cannot be reached, and

that it can trigger this kmalloc() warning for attempting an allocation

that is too large.