Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)

From: Theodore Ts'o
Date: Wed Jul 26 2023 - 21:10:19 EST


On Wed, Jul 26, 2023 at 06:45:55PM +0300, Dmitry Baryshkov wrote:
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
...
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017

> I highly suspect that the bisect was wrong here. The only thing that
> was changed by the mentioned commit is the device tree for the pretty
> obscure platform, which is not 'Google Compute Engine'.

Yeah, it's not even close. If you take a look at the bisection log
(which is *always* a good idea before you put any faith in the syzbot
bisection), you'd see the following:

testing commit e1c04510f521e853019afeca2a5991a5ef8d6a5b gcc
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
kernel signature: f262f513a4ba5708b69a5fdd8c218746223996a8b2134a22f2916d16f23d01e8
run #0: crashed: unregister_netdevice: waiting for DEV to become free
run #1: crashed: unregister_netdevice: waiting for DEV to become free
run #2: crashed: unregister_netdevice: waiting for DEV to become free
run #3: crashed: unregister_netdevice: waiting for DEV to become free
run #4: crashed: unregister_netdevice: waiting for DEV to become free
run #5: crashed: unregister_netdevice: waiting for DEV to become free
run #6: crashed: unregister_netdevice: waiting for DEV to become free
run #7: crashed: unregister_netdevice: waiting for DEV to become free
run #8: crashed: unregister_netdevice: waiting for DEV to become free

This is *nothing* like the problem reported on the dashboard, which is:

BUG: KASAN: use-after-free in instrument_atomic_read include/linux/instrumented.h:72 [inline]
BUG: KASAN: use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: use-after-free in qd_unlock+0x30/0x2d0 fs/gfs2/quota.c:490
Read of size 8 at addr ffff888073997090 by task syz-executor221/5069

where the dereference had a stack trace which looked like this:

_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
qd_unlock+0x30/0x2d0 fs/gfs2/quota.c:490
gfs2_quota_sync+0x768/0x8b0 fs/gfs2/quota.c:1325
gfs2_sync_fs+0x49/0xb0 fs/gfs2/super.c:650
sync_filesystem+0xe8/0x220 fs/sync.c:56
generic_shutdown_super+0x6b/0x310 fs/super.c:474
kill_block_super+0x79/0xd0 fs/super.c:1386
deactivate_locked_super+0xa7/0xf0 fs/super.c:332
cleanup_mnt+0x494/0x520 fs/namespace.c:1291
task_work_run+0x243/0x300 kernel/task_work.c:179
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x644/0x2150 kernel/exit.c:867

and the memory was allocated via this stack trace:

kmem_cache_alloc+0x1b3/0x350 mm/slub.c:3476
kmem_cache_zalloc include/linux/slab.h:710 [inline]
qd_alloc+0x51/0x250 fs/gfs2/quota.c:216
gfs2_quota_init+0x7c4/0x10e0 fs/gfs2/quota.c:1415
gfs2_make_fs_rw+0x48e/0x590 fs/gfs2/super.c:153
gfs2_fill_super+0x2357/0x2700 fs/gfs2/ops_fstype.c:1274
get_tree_bdev+0x400/0x620 fs/super.c:1282
gfs2_get_tree+0x50/0x210 fs/gfs2/ops_fstype.c:1330
vfs_get_tree+0x88/0x270 fs/super.c:1489
do_new_mount+0x289/0xad0 fs/namespace.c:3145
do_mount fs/namespace.c:3488 [inline]
__do_sys_mount fs/namespace.c:3697 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80

(And the memory was freed from an RCU path)

- Ted