CVE-2025-38196

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: validate buffer count with offset for cloning<br /> <br /> syzbot reports that it can trigger a WARN_ON() for kmalloc() attempt<br /> that&amp;#39;s too big:<br /> <br /> WARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024<br /> lr : __do_kmalloc_node mm/slub.c:-1 [inline]<br /> lr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012<br /> sp : ffff80009cfd7a90<br /> x29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0<br /> x26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000<br /> x23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8<br /> x20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff<br /> x17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005<br /> x14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938<br /> x8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000<br /> x2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)<br /> kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]<br /> io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]<br /> io_clone_buffers io_uring/rsrc.c:1178 [inline]<br /> io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287<br /> __io_uring_register io_uring/register.c:815 [inline]<br /> __do_sys_io_uring_register io_uring/register.c:926 [inline]<br /> __se_sys_io_uring_register io_uring/register.c:903 [inline]<br /> __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> <br /> which is due to offset + buffer_count being too large. The registration<br /> code checks only the total count of buffers, but given that the indexing<br /> is an array, it should also check offset + count. That can&amp;#39;t exceed<br /> IORING_MAX_REG_BUFFERS either, as there&amp;#39;s no way to reach buffers beyond<br /> that limit.<br /> <br /> There&amp;#39;s no issue with registrering a table this large, outside of the<br /> fact that it&amp;#39;s pointless to register buffers that cannot be reached, and<br /> that it can trigger this kmalloc() warning for attempting an allocation<br /> that is too large.