[Android 6.1] KASAN: use-after-free Read in ext4_convert_inline_data_nolock (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 92668decd5e0 UPSTREAM: locking/rtmutex: Skip remove_waiter..
git tree: android14-6.1
console output: https://syzkaller.appspot.com/x/log.txt?x=13e4f5b9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6af0777879025b2
dashboard link: https://syzkaller.appspot.com/bug?extid=0dd83d00e975fdccfacf
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12124c9e580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1287a5b9580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d489fb35aec8/disk-92668dec.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/33e640edad62/vmlinux-92668dec.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e0bb511e52c2/bzImage-92668dec.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/457d4b83f1ac/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=16d294c6580000)
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/19c196f62743/mount_8.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=1487a5b9580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0dd83d...@syzkaller.appspotmail.com

EXT4-fs (loop2): encrypted files will use data=ordered instead of data journaling mode
EXT4-fs (loop2): 1 truncate cleaned up
EXT4-fs (loop2): mounted filesystem without journal. Quota mode: none.
==================================================================
BUG: KASAN: use-after-free in ext4_read_inline_data fs/ext4/inline.c:210 [inline]
BUG: KASAN: use-after-free in ext4_convert_inline_data_nolock+0x30e/0x9e0 fs/ext4/inline.c:1234
Read of size 68 at addr ffff88812c6bac80 by task syz.2.17/375

CPU: 1 PID: 375 Comm: syz.2.17 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Call Trace:
<TASK>
__dump_stack+0x21/0x24 lib/dump_stack.c:88
dump_stack_lvl+0x110/0x170 lib/dump_stack.c:106
print_address_description+0x71/0x200 mm/kasan/report.c:316
print_report+0x4a/0x60 mm/kasan/report.c:420
kasan_report+0x122/0x150 mm/kasan/report.c:524
check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x249/0x2a0 mm/kasan/generic.c:189
memcpy+0x2d/0x70 mm/kasan/shadow.c:65
ext4_read_inline_data fs/ext4/inline.c:210 [inline]
ext4_convert_inline_data_nolock+0x30e/0x9e0 fs/ext4/inline.c:1234
ext4_try_add_inline_entry+0x732/0xa60 fs/ext4/inline.c:1360
ext4_add_entry+0x509/0xda0 fs/ext4/namei.c:2458
ext4_mkdir+0x520/0xc90 fs/ext4/namei.c:3081
vfs_mkdir+0x39c/0x580 fs/namei.c:4113
do_mkdirat+0x174/0x4d0 fs/namei.c:4138
__do_sys_mkdirat fs/namei.c:4153 [inline]
__se_sys_mkdirat fs/namei.c:4151 [inline]
__x64_sys_mkdirat+0x89/0xa0 fs/namei.c:4151
x64_sys_call+0x73d/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:259
do_syscall_x64 arch/x86/entry/common.c:46 [inline]
do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:76
entry_SYSCALL_64_after_hwframe+0x68/0xd2
RIP: 0033:0x7f86fbd9ce87
Code: 00 66 90 48 89 f2 b9 00 01 00 00 48 89 fe bf 9c ff ff ff e9 db f7 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 b8 02 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd0c6b8b08 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007ffd0c6b8b90 RCX: 00007f86fbd9ce87
RDX: 00000000000001ff RSI: 0000200000000080 RDI: 00000000ffffff9c
RBP: 0000200000000140 R08: 0000200000000080 R09: 0000000000000000
R10: 0000200000000140 R11: 0000000000000246 R12: 0000200000000080
R13: 00007ffd0c6b8b50 R14: 0000000000000000 R15: 0000000000000000
</TASK>

Allocated by task 309:
kasan_save_stack mm/kasan/common.c:46 [inline]
kasan_set_track+0x4b/0x70 mm/kasan/common.c:53
kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505
__kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:334
kasan_slab_alloc include/linux/kasan.h:202 [inline]
slab_post_alloc_hook+0x4f/0x2d0 mm/slab.h:768
slab_alloc_node mm/slub.c:3382 [inline]
slab_alloc mm/slub.c:3392 [inline]
__kmem_cache_alloc_lru mm/slub.c:3399 [inline]
kmem_cache_alloc+0x166/0x320 mm/slub.c:3408
vma_lock_alloc kernel/fork.c:471 [inline]
vm_area_dup+0x65/0x280 kernel/fork.c:524
__split_vma+0x1c6/0x980 mm/mmap.c:2440
do_mas_align_munmap+0x314/0x1330 mm/mmap.c:2567
do_mas_munmap+0x23d/0x2b0 mm/mmap.c:2751
__vm_munmap+0x1af/0x310 mm/mmap.c:3050
__do_sys_munmap mm/mmap.c:3076 [inline]
__se_sys_munmap mm/mmap.c:3072 [inline]
__x64_sys_munmap+0x6b/0x80 mm/mmap.c:3072
x64_sys_call+0x8a/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:12
do_syscall_x64 arch/x86/entry/common.c:46 [inline]
do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:76
entry_SYSCALL_64_after_hwframe+0x68/0xd2

Freed by task 13:
kasan_save_stack mm/kasan/common.c:46 [inline]
kasan_set_track+0x4b/0x70 mm/kasan/common.c:53
kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516
____kasan_slab_free+0x132/0x180 mm/kasan/common.c:242
__kasan_slab_free+0x11/0x20 mm/kasan/common.c:250
kasan_slab_free include/linux/kasan.h:178 [inline]
slab_free_hook mm/slub.c:1750 [inline]
slab_free_freelist_hook+0xc2/0x190 mm/slub.c:1776
slab_free mm/slub.c:3712 [inline]
kmem_cache_free+0x12d/0x300 mm/slub.c:3737
vma_lock_free kernel/fork.c:483 [inline]
__vm_area_free+0x6f/0x130 kernel/fork.c:537
vm_area_free_rcu_cb+0x15/0x20 kernel/fork.c:549
rcu_do_batch+0x52b/0xc30 kernel/rcu/tree.c:2297
rcu_core+0x486/0xf00 kernel/rcu/tree.c:2557
rcu_core_si+0x9/0x10 kernel/rcu/tree.c:2574
handle_softirqs+0x1d7/0x600 kernel/softirq.c:642
run_ksoftirqd+0x28/0x30 kernel/softirq.c:1019
smpboot_thread_fn+0x48c/0x8e0 kernel/smpboot.c:164
kthread+0x281/0x320 kernel/kthread.c:386
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

The buggy address belongs to the object at ffff88812c6bac60
which belongs to the cache vma_lock of size 64
The buggy address is located 32 bytes inside of
64-byte region [ffff88812c6bac60, ffff88812c6baca0)

The buggy address belongs to the physical page:
page:ffffea0004b1ae80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c6ba
flags: 0x4000000000000200(slab|zone=1)
raw: 4000000000000200 0000000000000000 dead000000000122 ffff8881001eaf00
raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 309, tgid 309 (udevd), ts 26731233292, free_ts 26024953530
set_page_owner include/linux/page_owner.h:33 [inline]
post_alloc_hook+0x1f5/0x210 mm/page_alloc.c:2672
prep_new_page+0x1c/0x110 mm/page_alloc.c:2679
get_page_from_freelist+0x2ca9/0x2d20 mm/page_alloc.c:4586
__alloc_pages+0x1fa/0x610 mm/page_alloc.c:5930
alloc_slab_page+0x6e/0xf0 include/linux/gfp.h:-1
allocate_slab mm/slub.c:1967 [inline]
new_slab+0x98/0x3e0 mm/slub.c:2020
___slab_alloc+0x70f/0xb70 mm/slub.c:3177
__slab_alloc+0x5e/0xa0 mm/slub.c:3263
slab_alloc_node mm/slub.c:3348 [inline]
slab_alloc mm/slub.c:3392 [inline]
__kmem_cache_alloc_lru mm/slub.c:3399 [inline]
kmem_cache_alloc+0x1a8/0x320 mm/slub.c:3408
vma_lock_alloc kernel/fork.c:471 [inline]
vm_area_dup+0x65/0x280 kernel/fork.c:524
__split_vma+0x1c6/0x980 mm/mmap.c:2440
do_mas_align_munmap+0x314/0x1330 mm/mmap.c:2567
do_mas_munmap+0x23d/0x2b0 mm/mmap.c:2751
__vm_munmap+0x1af/0x310 mm/mmap.c:3050
__do_sys_munmap mm/mmap.c:3076 [inline]
__se_sys_munmap mm/mmap.c:3072 [inline]
__x64_sys_munmap+0x6b/0x80 mm/mmap.c:3072
x64_sys_call+0x8a/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:12
page last free stack trace:
reset_page_owner include/linux/page_owner.h:26 [inline]
free_pages_prepare mm/page_alloc.c:1580 [inline]
free_pcp_prepare mm/page_alloc.c:1654 [inline]
free_unref_page_prepare+0x80c/0x820 mm/page_alloc.c:3621
free_unref_page+0x93/0x530 mm/page_alloc.c:3719
free_the_page mm/page_alloc.c:863 [inline]
__free_pages+0x67/0x100 mm/page_alloc.c:6020
__vunmap+0xa3c/0xc00 mm/vmalloc.c:2739
__vfree mm/vmalloc.c:2788 [inline]
vfree+0x61/0x90 mm/vmalloc.c:2819
kcov_put kernel/kcov.c:437 [inline]
kcov_close+0x2b/0x50 kernel/kcov.c:533
__fput+0x1fd/0x8f0 fs/file_table.c:320
____fput+0x15/0x20 fs/file_table.c:348
task_work_run+0x1e1/0x250 kernel/task_work.c:203
exit_task_work include/linux/task_work.h:39 [inline]
do_exit+0xaf2/0x2850 kernel/exit.c:887
do_group_exit+0x21b/0x2e0 kernel/exit.c:1030
get_signal+0x167c/0x1700 kernel/signal.c:2895
arch_do_signal_or_restart+0xd1/0x11c0 arch/x86/kernel/signal.c:871
exit_to_user_mode_loop+0x7a/0xb0 kernel/entry/common.c:174
exit_to_user_mode_prepare+0x87/0xd0 kernel/entry/common.c:210
__syscall_exit_to_user_mode_work kernel/entry/common.c:292 [inline]
syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:303

Memory state around the buggy address:
ffff88812c6bab80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88812c6bac00: 00 00 00 00 00 00 00 00 fc fc fc fc fa fb fb fb
>ffff88812c6bac80: fb fb fb fb fc fc fc fc fa fb fb fb fb fb fb fb
^
ffff88812c6bad00: fc fc fc fc 00 00 00 00 00 00 00 00 fc fc fc fc
ffff88812c6bad80: 00 00 00 00 00 00 00 00 fc fc fc fc 00 00 00 00
==================================================================
EXT4-fs error (device loop2): ext4_check_all_de:666: inode #12: block 7: comm syz.2.17: bad entry in directory: directory entry overrun - offset=0, inode=901261600, rec_len=7976, size=124 fake=0


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup