Re: Potential Linux Crash: KASAN slab-out-of-bounds Read in ext4_find_extent in Linux kernel v6.13-rc5

[Baokun Li <libaokun1@huawei.com>]

On 2025/3/6 11:08, Luka wrote:
> Dear Linux Kernel Experts,
>
> Hello!
>
> I am a security researcher focused on testing Linux kernel
> vulnerabilities. Recently, while testing the v6.13-rc5 Linux kernel,
> we encountered a crash related to the fs/ext4 kernel module. We have
> successfully captured the call trace information for this crash.
>
> Unfortunately, we have not been able to reproduce the issue in our
> local environment, so we are unable to provide a PoC (Proof of
> Concept) at this time.
>
> We fully understand the complexity and importance of Linux kernel
> maintenance, and we would like to share this finding with you for
> further analysis and confirmation of the root cause. Below is a
> summary of the relevant information:
>
> Kernel Version: v6.13-rc5
>
> Kernel Module: fs/ext4/extents.c
>
> ————————————————CallTrace————————————————
>
> BUG: KASAN: slab-out-of-bounds in ext4_ext_binsearch
> fs/ext4/extents.c:840 [inline]
> BUG: KASAN: slab-out-of-bounds in ext4_find_extent+0x9b8/0xa00
> fs/ext4/extents.c:955
> Read of size 4 at addr ffff888107037aa0 by task kworker/u16:3/50
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> Workqueue: writeback wb_workfn (flush-7:6)
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:94 [inline]
>   dump_stack_lvl+0x7b/0xa0 lib/dump_stack.c:120
>   print_address_description mm/kasan/report.c:378 [inline]
>   print_report+0xce/0x660 mm/kasan/report.c:489
>   kasan_report+0xc6/0x100 mm/kasan/report.c:602
>   ext4_ext_binsearch fs/ext4/extents.c:840 [inline]
>   ext4_find_extent+0x9b8/0xa00 fs/ext4/extents.c:955
>   ext4_ext_map_blocks+0x1bc/0x4e70 fs/ext4/extents.c:4205
>   ext4_map_create_blocks fs/ext4/inode.c:516 [inline]
>   ext4_map_blocks+0x3c8/0x11c0 fs/ext4/inode.c:702
>   mpage_map_one_extent fs/ext4/inode.c:2219 [inline]
>   mpage_map_and_submit_extent fs/ext4/inode.c:2272 [inline]
>   ext4_do_writepages+0x15b1/0x3040 fs/ext4/inode.c:2735
>   ext4_writepages+0x275/0x510 fs/ext4/inode.c:2824
>   do_writepages+0x197/0x7b0 mm/page-writeback.c:2702
>   __writeback_single_inode+0xe5/0x950 fs/fs-writeback.c:1680
>   writeback_sb_inodes+0x593/0xd00 fs/fs-writeback.c:1976
>   wb_writeback+0x188/0x790 fs/fs-writeback.c:2156
>   wb_do_writeback fs/fs-writeback.c:2303 [inline]
>   wb_workfn+0x1d2/0xa50 fs/fs-writeback.c:2343
>   process_one_work+0x61a/0x1050 kernel/workqueue.c:3229
>   process_scheduled_works kernel/workqueue.c:3310 [inline]
>   worker_thread+0x8cc/0x1160 kernel/workqueue.c:3391
>   kthread+0x25a/0x330 kernel/kthread.c:389
>   ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>   </TASK>
>
> Allocated by task 5054:
>   kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
>   kasan_save_track+0x14/0x30 mm/kasan/common.c:68
>   unpoison_slab_object mm/kasan/common.c:319 [inline]
>   __kasan_slab_alloc+0x6e/0x70 mm/kasan/common.c:345
>   kasan_slab_alloc include/linux/kasan.h:250 [inline]
>   slab_post_alloc_hook mm/slub.c:4119 [inline]
>   slab_alloc_node mm/slub.c:4168 [inline]
>   kmem_cache_alloc_noprof+0xf5/0x360 mm/slub.c:4175
>   getname_flags.part.0+0x48/0x4e0 fs/namei.c:139
>   getname_flags include/linux/audit.h:322 [inline]
>   getname+0x84/0xd0 fs/namei.c:223
>   getname_maybe_null include/linux/fs.h:2796 [inline]
>   vfs_fstatat fs/stat.c:361 [inline]
>   vfs_stat include/linux/fs.h:3392 [inline]
>   __do_sys_newstat+0x93/0x130 fs/stat.c:503
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 5054:
>   kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
>   kasan_save_track+0x14/0x30 mm/kasan/common.c:68
>   kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:582
>   poison_slab_object mm/kasan/common.c:247 [inline]
>   __kasan_slab_free+0x37/0x50 mm/kasan/common.c:264
>   kasan_slab_free include/linux/kasan.h:233 [inline]
>   slab_free_hook mm/slub.c:2353 [inline]
>   slab_free mm/slub.c:4613 [inline]
>   kmem_cache_free+0xec/0x380 mm/slub.c:4715
>   putname+0x111/0x150 fs/namei.c:296
>   vfs_fstatat fs/stat.c:367 [inline]
>   vfs_stat include/linux/fs.h:3392 [inline]
>   __do_sys_newstat+0xbc/0x130 fs/stat.c:503
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xa6/0x1a0 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
>
>
> ————————————————CallTrace————————————————
>
> If you need more details or additional test results, please feel free
> to let us know. Thank you so much for your attention! Please don't
> hesitate to reach out if you have any suggestions or need further
> communication.
>
> Best regards,
> Luka
>
Is there a reliable reproducer? Was CONFIG_BLK_DEV_WRITE_MOUNTED disabled
during testing? This appears to be a known issue caused by writing to a
bare disk.

The other two look like they might be the same thing:

https://lore.kernel.org/all/CALm_T+3qoQAChNSzULwKOvYDmvkxC8U5moKM5JEVRocR62s3yQ@mail.gmail.com
https://lore.kernel.org/all/CALm_T+1DnSQRHiyO3c1-H4rRnBJHKRMpfQYQMGN=yZROm7tYKQ@mail.gmail.com