[BUG] ext4: KASAN slab-use-after-free in __ext4_check_dir_entry during getdents64 on corrupted directory

[ZW Tang]

Hi,

I am reporting a KASAN slab-use-after-free triggered by a syzkaller
reproducer on Linux 7.1.0-rc5. The issue is hit while reading an ext4
directory from a crafted filesystem image.

The reproducer mounts a corrupted ext4 image through
syz_mount_image$ext4, opens the current directory, seeks the directory
fd, and then calls getdents64(). The kernel first reports ext4 dx
directory corruption, and then KASAN reports a slab-use-after-free in
__ext4_check_dir_entry().

This looks like ext4 continues directory entry validation after
encountering corrupted dx/htree directory metadata, and
__ext4_check_dir_entry() ends up reading from an invalid/freed object
instead of safely rejecting the corrupted directory.

Reproducer:
C reproducer: https://pastebin.com/PJjfHECH
console output:https://pastebin.com/s9jBugWd
kernel config: https://pastebin.com/raw/fUwrL2uz

Kernel:
HEAD commit: e7ae89a0c97c
kernel version: 7.1.0-rc5 #2 PREEMPT(lazy)
Hardware: QEMU Ubuntu 24.10 PC (i440FX + PIIX, 1996)
Taint: Not tainted

EXT4 warnings before the KASAN report:

EXT4-fs warning (device loop3): dx_probe:800: inode #2: comm syz.3.4:
Unrecognised inode hash code 20
EXT4-fs warning (device loop3): dx_probe:933: inode #2: comm syz.3.4:
Corrupt directory, running e2fsck is recommended

KASAN report:

BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x670/0x720
Read of size 2 at addr ffff88811074d003 by task syz.3.4/2047

Call Trace:
<TASK>
dump_stack_lvl+0x7d/0xa0
print_report+0x10d/0x5d0
kasan_report+0x96/0xd0
__ext4_check_dir_entry+0x670/0x720
ext4_readdir+0xd7b/0x27c0
iterate_dir+0x1c0/0x570
__x64_sys_getdents64+0x134/0x260
do_syscall_64+0x104/0x5b0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>

The buggy address belongs to a freed object from the vm_area_struct cache:

The buggy address belongs to the object at ffff88811074d000
which belongs to the cache vm_area_struct of size 192
The buggy address is located 3 bytes inside of
freed 192-byte region [ffff88811074d000, ffff88811074d0c0)

Allocated by task 1892:
__kasan_slab_alloc
kmem_cache_alloc_noprof
vm_area_alloc
__mmap_region
mmap_region
do_mmap
vm_mmap_pgoff
ksys_mmap_pgoff
__x64_sys_mmap
do_syscall_64
entry_SYSCALL_64_after_hwframe

Freed by task 1891:
__kasan_slab_free
slab_free_after_rcu_debug
rcu_core
handle_softirqs
irq_exit_rcu
sysvec_apic_timer_interrupt
asm_sysvec_apic_timer_interrupt

The direct trigger path appears to be:

getdents64()
iterate_dir()
ext4_readdir()
__ext4_check_dir_entry()

Since the reproducer first reports a corrupted ext4 dx directory and
then crashes inside __ext4_check_dir_entry(), the issue seems to be in
ext4 directory iteration / directory entry validation handling of
corrupted directory metadata.

Thanks.