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

[Jens Axboe <axboe@kernel.dk>]

On 11/10/25 1:37 PM, Jens Axboe wrote:
> 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?!

Ah nevermind, I see what this is now. We can still alloc for lower
counts, if we don't have a persistent one already.

-- 
Jens Axboe