[BUG] jfs: KASAN slab-use-after-free in jfs_lazycommit

[ZW Tang]

Hi,

I am reporting a KASAN slab-use-after-free triggered by a syzkaller
reproducer on Linux 7.2-rc3.

Although a similar bug has been reported and fixed before, I can still
trigger this issue on Linux 7.2-rc3 with the attached syzkaller
reproducer. (https://syzkaller.appspot.com/bug?id=5d51917f70e46296ba715592e97c8fb2d1d99118)

The reproducer mounts crafted JFS images with syz_mount_image$jfs. After
repeated mount/cleanup activity, the jfsCommit kernel thread accesses an
object that has already been freed during superblock shutdown. The crash
happens in jfs_lazycommit().

This looks like a JFS lifetime / teardown synchronization issue between
JFS mount/unmount cleanup and the lazy commit thread, rather than a
generic KASAN or VFS problem.

Reproducer:
syz reproducer: https://pastebin.com/raw/UyX7TUdn
kernel config: https://pastebin.com/raw/uTaJS8Np
console output: https://pastebin.com/raw/mRWt7Zpy

Kernel:
HEAD commit: 1137d8b5df06137fb49513cc923b3b24d94cb809
git tree: torvalds/linux
kernel version: 7.2.0-rc3 #1 PREEMPT(full) (QEMU Ubuntu 24.10)

Crash log excerpt:

BUG: KASAN: slab-use-after-free in jfs_lazycommit+0xabe/0xb40
Read of size 4 at addr ffff88804f3cd694 by task jfsCommit/117

CPU: 0 UID: 0 PID: 117 Comm: jfsCommit Not tainted 7.2.0-rc3 #1 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.10 PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014

Call Trace:
<TASK>
dump_stack_lvl+0x116/0x1b0
print_report+0xfb/0x5c0
kasan_report+0x96/0xd0
jfs_lazycommit+0xabe/0xb40
kthread+0x404/0x530
ret_from_fork+0x7c5/0xde0
ret_from_fork_asm+0x1a/0x30
</TASK>

The object was allocated from the JFS mount path:

Allocated by task 22373:
__kmalloc_cache_noprof+0x2dc/0x780
jfs_fill_super+0xd1/0x1080
get_tree_bdev_flags+0x38a/0x620
vfs_get_tree+0x97/0x3b0
fc_mount+0x18/0x110
path_mount+0x777/0x1e20
do_mount+0xc5/0x120
__x64_sys_mount+0x193/0x230

The same object was later freed during superblock teardown:

Freed by task 19348:
kfree+0x2ac/0x6d0
generic_shutdown_super+0x166/0x400
kill_block_super+0x3b/0x90
deactivate_locked_super+0xbb/0x130
deactivate_super+0xb1/0xd0
cleanup_mnt+0x378/0x510
task_work_run+0x172/0x280
exit_to_user_mode_loop+0x201/0x660

KASAN reports that the buggy address is 148 bytes inside a freed
kmalloc-256 object:

The buggy address belongs to the object at ffff88804f3cd600
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 148 bytes inside of
freed 256-byte region [ffff88804f3cd600, ffff88804f3cd700)

This suggests that jfs_lazycommit() can still observe or dereference
JFS state after the corresponding superblock-private object has already
been released during unmount/cleanup.

Thanks