[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bb64cc89-194f-4626-a048-0692239f65dd@kernel.dk>
Date: Mon, 10 Nov 2025 13:37:07 -0700
From: Jens Axboe <axboe@...nel.dk>
To: syzbot <syzbot+3c93637d7648c24e1fd0@...kaller.appspotmail.com>,
io-uring@...r.kernel.org, linux-kernel@...r.kernel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [io-uring?] memory leak in iovec_from_user (2)
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@...kaller.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
Powered by blists - more mailing lists