linux-kernel - Re: [syzbot] [io-uring?] memory leak in iovec_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cda9eb1a-9902-4961-aed0-66b5e94dd3f6@kernel.dk>
Date: Mon, 12 Jan 2026 12:36:00 -0700
From: Jens Axboe <axboe@...nel.dk>
To: syzbot <syzbot+abecd272a5e56fcef099@...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 (3)

On 1/12/26 11:23 AM, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    7143203341dc Merge tag 'libcrypto-for-linus' of git://git...
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=177fd9fc580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=87bc41cae23d2144
> dashboard link: https://syzkaller.appspot.com/bug?extid=abecd272a5e56fcef099
> 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=12f4399a580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11ab3c3a580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/1efe18c6d01c/disk-71432033.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/a5a0b8a88b2b/vmlinux-71432033.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/5bd4c64b0a42/bzImage-71432033.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+abecd272a5e56fcef099@...kaller.appspotmail.com

I can't reproduce this, and I have a sneaking suspicion that this is mostly
just timing on kmemleak scanning. I've seen that a few times. Just running
your reproducer and I see:

root@...ian:~# cat /sys/kernel/debug/kmemleak 
unreferenced object 0xff110000964a6200 (size 200):
  comm "kworker/u32:7", pid 1149, jiffies 4294971353
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 c0 92 73 00 01 00 11 ff  ..........s.....
    01 30 90 00 00 05 04 40 00 00 00 00 01 00 00 00  .0.....@........
  backtrace (crc 38936ccb):
    kmem_cache_alloc_noprof+0x3fe/0x580
    mempool_alloc_noprof+0xb9/0x190
    bio_alloc_bioset+0x561/0x760
    submit_bh_wbc+0x130/0x250
    __block_write_full_folio+0x3ad/0x720
    block_write_full_folio+0x14c/0x180
    blkdev_writepages+0x6c/0xd0
    do_writepages+0xe9/0x1f0
    __writeback_single_inode+0x5e/0x600
    writeback_sb_inodes+0x2ea/0x850
    __writeback_inodes_wb+0x5c/0x150
    wb_writeback+0x382/0x4d0
    wb_workfn+0x4d2/0x640
    process_one_work+0x260/0x580
    worker_thread+0x2b3/0x4e0
    kthread+0x161/0x310

which are obviously temporal, and a whole bunch of the same reports, in
fact there is:

root@...ian:~# cat /sys/kernel/debug/kmemleak | wc -l
264

lines in there. Then let's trigger a new scan:

root@...ian:~# echo scan > /sys/kernel/debug/kmemleak 
root@...ian:~# cat /sys/kernel/debug/kmemleak | wc -l
0

and they are all gone.

#syz invalid

-- 
Jens Axboe