Re: [syzbot] [io-uring?] memory leak in iovec_from_user (2)

[Jens Axboe <axboe@kernel.dk>]

On 11/10/25 11:09 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    4a0c9b339199 Merge tag 'probes-fixes-v6.18-rc4' of git://g..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=12af5342580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=cb128cd5cb439809
> dashboard link: https://syzkaller.appspot.com/bug?extid=3c93637d7648c24e1fd0
> compiler:       gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16af5342580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13664412580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/bfd02a09ef4d/disk-4a0c9b33.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/ed9a1334f973/vmlinux-4a0c9b33.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/e503329437ee/bzImage-4a0c9b33.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3c93637d7648c24e1fd0@syzkaller.appspotmail.com
> 
> BUG: memory leak
> unreferenced object 0xffff88812638cc20 (size 32):
>   comm "syz.0.17", pid 6104, jiffies 4294942640
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace (crc 0):
>     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
>     slab_post_alloc_hook mm/slub.c:4975 [inline]
>     slab_alloc_node mm/slub.c:5280 [inline]
>     __do_kmalloc_node mm/slub.c:5641 [inline]
>     __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5654
>     kmalloc_noprof include/linux/slab.h:961 [inline]
>     kmalloc_array_noprof include/linux/slab.h:1003 [inline]
>     iovec_from_user lib/iov_iter.c:1309 [inline]
>     iovec_from_user+0x108/0x140 lib/iov_iter.c:1292
>     __import_iovec+0x71/0x350 lib/iov_iter.c:1363
>     io_import_vec io_uring/rw.c:99 [inline]
>     __io_import_rw_buffer+0x1e2/0x260 io_uring/rw.c:120
>     io_import_rw_buffer io_uring/rw.c:139 [inline]
>     io_rw_do_import io_uring/rw.c:314 [inline]
>     io_prep_rw+0xb5/0x120 io_uring/rw.c:326
>     io_prep_rwv io_uring/rw.c:344 [inline]
>     io_prep_readv+0x20/0x80 io_uring/rw.c:359
>     io_init_req io_uring/io_uring.c:2248 [inline]
>     io_submit_sqe io_uring/io_uring.c:2295 [inline]
>     io_submit_sqes+0x354/0xe80 io_uring/io_uring.c:2447
>     __do_sys_io_uring_enter+0x83f/0xcf0 io_uring/io_uring.c:3514
>     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>     do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94
>     entry_SYSCALL_64_after_hwframe+0x77/0x7f

This one doesn't make any sense to me. The reproducer given only uses
a single segment, and hence could never hit the allocation path for
an iovec, it'd always just use the embedded vec?!

-- 
Jens Axboe