* [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-01-02 21:20 ` syzbot
0 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2023-01-02 21:20 UTC (permalink / raw)
To: agruenba, cluster-devel, linux-kernel, rpeterso, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 1b929c02afd3 Linux 6.2-rc1
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1799c250480000
kernel config: https://syzkaller.appspot.com/x/.config?x=68e0be42c8ee4bb4
dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14c4ea18480000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1359b338480000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2d8c5072480f/disk-1b929c02.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/46687f1395db/vmlinux-1b929c02.xz
kernel image: https://storage.googleapis.com/syzbot-assets/26f1afa5ec00/bzImage-1b929c02.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/35edd581b491/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2c431103d0
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
</TASK>
==================================================================
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
CPU: 1 PID: 5069 Comm: syz-executor221 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:306
print_report+0x107/0x1f0 mm/kasan/report.c:417
kasan_report+0xcd/0x100 mm/kasan/report.c:517
kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
instrument_atomic_read include/linux/instrumented.h:72 [inline]
_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
do_group_exit+0x1fd/0x2b0 kernel/exit.c:1012
__do_sys_exit_group kernel/exit.c:1023 [inline]
__se_sys_exit_group kernel/exit.c:1021 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1021
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f2c4308d0c9
Code: Unable to access opcode bytes at 0x7f2c4308d09f.
RSP: 002b:00007ffcdd2f81f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f2c431103d0 RCX: 00007f2c4308d0c9
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000012550
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2c431103d0
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
</TASK>
Allocated by task 5069:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
__kasan_slab_alloc+0x65/0x70 mm/kasan/common.c:325
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slab.h:761 [inline]
slab_alloc_node mm/slub.c:3452 [inline]
slab_alloc mm/slub.c:3460 [inline]
__kmem_cache_alloc_lru mm/slub.c:3467 [inline]
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
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 0:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518
____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
kasan_slab_free include/linux/kasan.h:177 [inline]
slab_free_hook mm/slub.c:1781 [inline]
slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807
slab_free mm/slub.c:3787 [inline]
kmem_cache_free+0x94/0x1d0 mm/slub.c:3809
rcu_do_batch kernel/rcu/tree.c:2246 [inline]
rcu_core+0x9c1/0x1690 kernel/rcu/tree.c:2506
__do_softirq+0x277/0x738 kernel/softirq.c:571
Last potentially related work creation:
kasan_save_stack+0x2b/0x50 mm/kasan/common.c:45
__kasan_record_aux_stack+0xb0/0xc0 mm/kasan/generic.c:488
__call_rcu_common kernel/rcu/tree.c:2755 [inline]
call_rcu+0x163/0xa70 kernel/rcu/tree.c:2868
gfs2_quota_cleanup+0x457/0x6b0 fs/gfs2/quota.c:1479
gfs2_make_fs_ro+0x517/0x610 fs/gfs2/super.c:560
signal_our_withdraw fs/gfs2/util.c:166 [inline]
gfs2_withdraw+0x609/0x1540 fs/gfs2/util.c:351
gfs2_dinode_in fs/gfs2/glops.c:460 [inline]
gfs2_inode_refresh+0xb2d/0xf60 fs/gfs2/glops.c:480
gfs2_instantiate+0x15e/0x220 fs/gfs2/glock.c:456
gfs2_glock_holder_ready fs/gfs2/glock.c:1299 [inline]
gfs2_glock_wait+0x1d9/0x2a0 fs/gfs2/glock.c:1319
gfs2_glock_nq_init fs/gfs2/glock.h:262 [inline]
do_sync+0x485/0xc80 fs/gfs2/quota.c:916
gfs2_quota_sync+0x3da/0x8b0 fs/gfs2/quota.c:1318
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
do_group_exit+0x1fd/0x2b0 kernel/exit.c:1012
__do_sys_exit_group kernel/exit.c:1023 [inline]
__se_sys_exit_group kernel/exit.c:1021 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1021
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff888073997000
which belongs to the cache gfs2_quotad of size 272
The buggy address is located 144 bytes inside of
272-byte region [ffff888073997000, ffff888073997110)
The buggy address belongs to the physical page:
page:ffffea0001ce65c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x73997
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffff8881461ae500 dead000000000122 0000000000000000
raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Reclaimable, gfp_mask 0x12c50(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_RECLAIMABLE), pid 5069, tgid 5069 (syz-executor221), ts 50927644511, free_ts 12661541703
prep_new_page mm/page_alloc.c:2531 [inline]
get_page_from_freelist+0x742/0x7c0 mm/page_alloc.c:4283
__alloc_pages+0x259/0x560 mm/page_alloc.c:5549
alloc_slab_page+0xbd/0x190 mm/slub.c:1851
allocate_slab+0x5e/0x3c0 mm/slub.c:1998
new_slab mm/slub.c:2051 [inline]
___slab_alloc+0x782/0xe20 mm/slub.c:3193
__slab_alloc mm/slub.c:3292 [inline]
__slab_alloc_node mm/slub.c:3345 [inline]
slab_alloc_node mm/slub.c:3442 [inline]
slab_alloc mm/slub.c:3460 [inline]
__kmem_cache_alloc_lru mm/slub.c:3467 [inline]
kmem_cache_alloc+0x268/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
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1446 [inline]
free_pcp_prepare+0x751/0x780 mm/page_alloc.c:1496
free_unref_page_prepare mm/page_alloc.c:3369 [inline]
free_unref_page+0x19/0x4c0 mm/page_alloc.c:3464
free_contig_range+0xa3/0x160 mm/page_alloc.c:9485
destroy_args+0xfe/0x940 mm/debug_vm_pgtable.c:998
debug_vm_pgtable+0x43d/0x4a0 mm/debug_vm_pgtable.c:1318
do_one_initcall+0x1d1/0x410 init/main.c:1306
do_initcall_level+0x168/0x220 init/main.c:1379
do_initcalls+0x43/0x90 init/main.c:1395
kernel_init_freeable+0x428/0x5e0 init/main.c:1634
kernel_init+0x19/0x2b0 init/main.c:1522
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
Memory state around the buggy address:
ffff888073996f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888073997000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888073997080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888073997100: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888073997180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
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 syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-01-02 21:20 ` syzbot
0 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2023-01-02 21:20 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hello,
syzbot found the following issue on:
HEAD commit: 1b929c02afd3 Linux 6.2-rc1
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=1799c250480000
kernel config: https://syzkaller.appspot.com/x/.config?x=68e0be42c8ee4bb4
dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14c4ea18480000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1359b338480000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2d8c5072480f/disk-1b929c02.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/46687f1395db/vmlinux-1b929c02.xz
kernel image: https://storage.googleapis.com/syzbot-assets/26f1afa5ec00/bzImage-1b929c02.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/35edd581b491/mount_0.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f6a670108ce43356017 at syzkaller.appspotmail.com
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2c431103d0
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
</TASK>
==================================================================
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
CPU: 1 PID: 5069 Comm: syz-executor221 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
print_address_description+0x74/0x340 mm/kasan/report.c:306
print_report+0x107/0x1f0 mm/kasan/report.c:417
kasan_report+0xcd/0x100 mm/kasan/report.c:517
kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189
instrument_atomic_read include/linux/instrumented.h:72 [inline]
_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
do_group_exit+0x1fd/0x2b0 kernel/exit.c:1012
__do_sys_exit_group kernel/exit.c:1023 [inline]
__se_sys_exit_group kernel/exit.c:1021 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1021
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f2c4308d0c9
Code: Unable to access opcode bytes at 0x7f2c4308d09f.
RSP: 002b:00007ffcdd2f81f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f2c431103d0 RCX: 00007f2c4308d0c9
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001
RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000012550
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2c431103d0
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
</TASK>
Allocated by task 5069:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
__kasan_slab_alloc+0x65/0x70 mm/kasan/common.c:325
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slab.h:761 [inline]
slab_alloc_node mm/slub.c:3452 [inline]
slab_alloc mm/slub.c:3460 [inline]
__kmem_cache_alloc_lru mm/slub.c:3467 [inline]
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
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 0:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518
____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
kasan_slab_free include/linux/kasan.h:177 [inline]
slab_free_hook mm/slub.c:1781 [inline]
slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807
slab_free mm/slub.c:3787 [inline]
kmem_cache_free+0x94/0x1d0 mm/slub.c:3809
rcu_do_batch kernel/rcu/tree.c:2246 [inline]
rcu_core+0x9c1/0x1690 kernel/rcu/tree.c:2506
__do_softirq+0x277/0x738 kernel/softirq.c:571
Last potentially related work creation:
kasan_save_stack+0x2b/0x50 mm/kasan/common.c:45
__kasan_record_aux_stack+0xb0/0xc0 mm/kasan/generic.c:488
__call_rcu_common kernel/rcu/tree.c:2755 [inline]
call_rcu+0x163/0xa70 kernel/rcu/tree.c:2868
gfs2_quota_cleanup+0x457/0x6b0 fs/gfs2/quota.c:1479
gfs2_make_fs_ro+0x517/0x610 fs/gfs2/super.c:560
signal_our_withdraw fs/gfs2/util.c:166 [inline]
gfs2_withdraw+0x609/0x1540 fs/gfs2/util.c:351
gfs2_dinode_in fs/gfs2/glops.c:460 [inline]
gfs2_inode_refresh+0xb2d/0xf60 fs/gfs2/glops.c:480
gfs2_instantiate+0x15e/0x220 fs/gfs2/glock.c:456
gfs2_glock_holder_ready fs/gfs2/glock.c:1299 [inline]
gfs2_glock_wait+0x1d9/0x2a0 fs/gfs2/glock.c:1319
gfs2_glock_nq_init fs/gfs2/glock.h:262 [inline]
do_sync+0x485/0xc80 fs/gfs2/quota.c:916
gfs2_quota_sync+0x3da/0x8b0 fs/gfs2/quota.c:1318
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
do_group_exit+0x1fd/0x2b0 kernel/exit.c:1012
__do_sys_exit_group kernel/exit.c:1023 [inline]
__se_sys_exit_group kernel/exit.c:1021 [inline]
__x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1021
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The buggy address belongs to the object at ffff888073997000
which belongs to the cache gfs2_quotad of size 272
The buggy address is located 144 bytes inside of
272-byte region [ffff888073997000, ffff888073997110)
The buggy address belongs to the physical page:
page:ffffea0001ce65c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x73997
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 ffff8881461ae500 dead000000000122 0000000000000000
raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Reclaimable, gfp_mask 0x12c50(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_RECLAIMABLE), pid 5069, tgid 5069 (syz-executor221), ts 50927644511, free_ts 12661541703
prep_new_page mm/page_alloc.c:2531 [inline]
get_page_from_freelist+0x742/0x7c0 mm/page_alloc.c:4283
__alloc_pages+0x259/0x560 mm/page_alloc.c:5549
alloc_slab_page+0xbd/0x190 mm/slub.c:1851
allocate_slab+0x5e/0x3c0 mm/slub.c:1998
new_slab mm/slub.c:2051 [inline]
___slab_alloc+0x782/0xe20 mm/slub.c:3193
__slab_alloc mm/slub.c:3292 [inline]
__slab_alloc_node mm/slub.c:3345 [inline]
slab_alloc_node mm/slub.c:3442 [inline]
slab_alloc mm/slub.c:3460 [inline]
__kmem_cache_alloc_lru mm/slub.c:3467 [inline]
kmem_cache_alloc+0x268/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
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1446 [inline]
free_pcp_prepare+0x751/0x780 mm/page_alloc.c:1496
free_unref_page_prepare mm/page_alloc.c:3369 [inline]
free_unref_page+0x19/0x4c0 mm/page_alloc.c:3464
free_contig_range+0xa3/0x160 mm/page_alloc.c:9485
destroy_args+0xfe/0x940 mm/debug_vm_pgtable.c:998
debug_vm_pgtable+0x43d/0x4a0 mm/debug_vm_pgtable.c:1318
do_one_initcall+0x1d1/0x410 init/main.c:1306
do_initcall_level+0x168/0x220 init/main.c:1379
do_initcalls+0x43/0x90 init/main.c:1395
kernel_init_freeable+0x428/0x5e0 init/main.c:1634
kernel_init+0x19/0x2b0 init/main.c:1522
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
Memory state around the buggy address:
ffff888073996f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888073997000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888073997080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888073997100: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888073997180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
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 syzkaller at googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-01-02 21:20 ` [Cluster-devel] " syzbot
(?)
@ 2023-01-27 5:10 ` eadavis
2023-01-30 14:32 ` [Cluster-devel] " Andreas Gruenbacher
2023-08-22 19:32 ` [Cluster-devel] " Bob Peterson
-1 siblings, 2 replies; 22+ messages in thread
From: eadavis @ 2023-01-27 5:10 UTC (permalink / raw)
To: cluster-devel.redhat.com
From: Edward Adam Davis <eadavis@sina.com>
[ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
[ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
[ 81.392343][ T5532] Call Trace:
[ 81.395654][ T5532] <TASK>
[ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
[ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
[ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
[ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
[ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
[ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
[ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
[ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
[ 81.516352][ T5532] do_sync+0x485/0xc80
[ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
[ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
[ 81.564063][ T5532] sync_filesystem+0xe8/0x220
[ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
[ 81.574112][ T5532] kill_block_super+0x79/0xd0
[ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
[ 81.584064][ T5532] cleanup_mnt+0x494/0x520
[ 81.593753][ T5532] task_work_run+0x243/0x300
[ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
[ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
[ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
[ 81.625287][ T5532] do_syscall_64+0x49/0xb0
[ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
[ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
[ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
[ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
[ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
[ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
[ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
[ 81.712868][ T5532] </TASK>
The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
"gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f at google.com
Reported-and-tested-by: syzbot+3f6a670108ce43356017 at syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@sina.com>
---
fs/gfs2/quota.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
index 1ed1722..4cf66bd 100644
--- a/fs/gfs2/quota.c
+++ b/fs/gfs2/quota.c
@@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
qda[x]->qd_sync_gen =
sdp->sd_quota_sync_gen;
+ if (!sdp->sd_quota_bitmap)
+ break;
+
for (x = 0; x < num_qd; x++)
qd_unlock(qda[x]);
}
--
2.39.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-01-27 5:10 ` [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync eadavis
@ 2023-01-30 14:32 ` Andreas Gruenbacher
2023-08-22 19:32 ` [Cluster-devel] " Bob Peterson
1 sibling, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-01-30 14:32 UTC (permalink / raw)
To: Edward Adam Davis
Cc: syzbot+3f6a670108ce43356017, cluster-devel, linux-kernel,
rpeterso, syzkaller-bugs
Hello Edward,
On Fri, Jan 27, 2023 at 6:12 AM <eadavis@sina.com> wrote:
> From: Edward Adam Davis <eadavis@sina.com>
>
> [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> [ 81.392343][ T5532] Call Trace:
> [ 81.395654][ T5532] <TASK>
> [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> [ 81.516352][ T5532] do_sync+0x485/0xc80
> [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> [ 81.593753][ T5532] task_work_run+0x243/0x300
> [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> [ 81.712868][ T5532] </TASK>
>
> The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
I can see that there is a problem in the gfs2 quota code, but this
unfortunately doesn't look like an acceptable fix. A better approach
would be to use proper reference counting for gfs2_quota_data objects.
In this case, gfs2_quota_sync() is still holding a reference, so the
underlying object shouldn't be freed.
Fixing this properly will require more than a handful of lines.
> Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
> Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> ---
> fs/gfs2/quota.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index 1ed1722..4cf66bd 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> qda[x]->qd_sync_gen =
> sdp->sd_quota_sync_gen;
>
> + if (!sdp->sd_quota_bitmap)
> + break;
> +
> for (x = 0; x < num_qd; x++)
> qd_unlock(qda[x]);
> }
> --
> 2.39.0
>
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
@ 2023-01-30 14:32 ` Andreas Gruenbacher
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-01-30 14:32 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hello Edward,
On Fri, Jan 27, 2023 at 6:12 AM <eadavis@sina.com> wrote:
> From: Edward Adam Davis <eadavis@sina.com>
>
> [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> [ 81.392343][ T5532] Call Trace:
> [ 81.395654][ T5532] <TASK>
> [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> [ 81.516352][ T5532] do_sync+0x485/0xc80
> [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> [ 81.593753][ T5532] task_work_run+0x243/0x300
> [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> [ 81.712868][ T5532] </TASK>
>
> The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
I can see that there is a problem in the gfs2 quota code, but this
unfortunately doesn't look like an acceptable fix. A better approach
would be to use proper reference counting for gfs2_quota_data objects.
In this case, gfs2_quota_sync() is still holding a reference, so the
underlying object shouldn't be freed.
Fixing this properly will require more than a handful of lines.
> Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f at google.com
> Reported-and-tested-by: syzbot+3f6a670108ce43356017 at syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> ---
> fs/gfs2/quota.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index 1ed1722..4cf66bd 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> qda[x]->qd_sync_gen =
> sdp->sd_quota_sync_gen;
>
> + if (!sdp->sd_quota_bitmap)
> + break;
> +
> for (x = 0; x < num_qd; x++)
> qd_unlock(qda[x]);
> }
> --
> 2.39.0
>
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
2023-01-02 21:20 ` [Cluster-devel] " syzbot
@ 2023-07-26 15:03 ` syzbot
-1 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2023-07-26 15:03 UTC (permalink / raw)
To: agruenba, andersson, cluster-devel, dmitry.baryshkov, eadavis,
konrad.dybcio, linux-fsdevel, linux-kernel, rpeterso,
syzkaller-bugs
syzbot suspects this issue was fixed by commit:
commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Mon Dec 26 04:21:51 2022 +0000
arm64: dts: qcom: qcs404: use symbol names for PCIe resets
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
start commit: [unknown]
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-07-26 15:03 ` syzbot
0 siblings, 0 replies; 22+ messages in thread
From: syzbot @ 2023-07-26 15:03 UTC (permalink / raw)
To: cluster-devel.redhat.com
syzbot suspects this issue was fixed by commit:
commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Mon Dec 26 04:21:51 2022 +0000
arm64: dts: qcom: qcs404: use symbol names for PCIe resets
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
start commit: [unknown]
git tree: upstream
kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
If the result looks correct, please mark the issue as fixed by replying with:
#syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
2023-07-26 15:03 ` [Cluster-devel] " syzbot
@ 2023-07-26 15:09 ` Aleksandr Nogikh
-1 siblings, 0 replies; 22+ messages in thread
From: Aleksandr Nogikh @ 2023-07-26 15:09 UTC (permalink / raw)
To: syzbot
Cc: agruenba, andersson, cluster-devel, dmitry.baryshkov, eadavis,
konrad.dybcio, linux-fsdevel, linux-kernel, rpeterso,
syzkaller-bugs
On Wed, Jul 26, 2023 at 5:03 PM syzbot
<syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com> wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Date: Mon Dec 26 04:21:51 2022 +0000
>
> arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> start commit: [unknown]
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
>
> If the result looks correct, please mark the issue as fixed by replying with:
No, it's quite unlikely.
>
> #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000009655cc060165265f%40google.com.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-07-26 15:09 ` Aleksandr Nogikh
0 siblings, 0 replies; 22+ messages in thread
From: Aleksandr Nogikh @ 2023-07-26 15:09 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Wed, Jul 26, 2023 at 5:03?PM syzbot
<syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com> wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Date: Mon Dec 26 04:21:51 2022 +0000
>
> arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> start commit: [unknown]
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
>
> If the result looks correct, please mark the issue as fixed by replying with:
No, it's quite unlikely.
>
> #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000009655cc060165265f%40google.com.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
2023-07-26 15:09 ` [Cluster-devel] " Aleksandr Nogikh
@ 2023-07-26 15:45 ` Dmitry Baryshkov
-1 siblings, 0 replies; 22+ messages in thread
From: Dmitry Baryshkov @ 2023-07-26 15:45 UTC (permalink / raw)
To: Aleksandr Nogikh
Cc: syzbot, agruenba, andersson, cluster-devel, eadavis,
konrad.dybcio, linux-fsdevel, linux-kernel, rpeterso,
syzkaller-bugs
On Wed, 26 Jul 2023 at 18:09, Aleksandr Nogikh <nogikh@google.com> wrote:
>
> On Wed, Jul 26, 2023 at 5:03 PM syzbot
> <syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com> wrote:
> >
> > syzbot suspects this issue was fixed by commit:
> >
> > commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> > Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Date: Mon Dec 26 04:21:51 2022 +0000
> >
> > arm64: dts: qcom: qcs404: use symbol names for PCIe resets
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> > start commit: [unknown]
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
> >
> > If the result looks correct, please mark the issue as fixed by replying with:
>
> No, it's quite unlikely.
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'.
>
> >
> > #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-07-26 15:45 ` Dmitry Baryshkov
0 siblings, 0 replies; 22+ messages in thread
From: Dmitry Baryshkov @ 2023-07-26 15:45 UTC (permalink / raw)
To: cluster-devel.redhat.com
On Wed, 26 Jul 2023 at 18:09, Aleksandr Nogikh <nogikh@google.com> wrote:
>
> On Wed, Jul 26, 2023 at 5:03?PM syzbot
> <syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com> wrote:
> >
> > syzbot suspects this issue was fixed by commit:
> >
> > commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> > Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Date: Mon Dec 26 04:21:51 2022 +0000
> >
> > arm64: dts: qcom: qcs404: use symbol names for PCIe resets
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> > start commit: [unknown]
> > git tree: upstream
> > kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
> >
> > If the result looks correct, please mark the issue as fixed by replying with:
>
> No, it's quite unlikely.
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'.
>
> >
> > #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
2023-07-26 15:03 ` [Cluster-devel] " syzbot
@ 2023-07-26 16:14 ` Bob Peterson
-1 siblings, 0 replies; 22+ messages in thread
From: Bob Peterson @ 2023-07-26 16:14 UTC (permalink / raw)
To: syzbot, agruenba, andersson, cluster-devel, dmitry.baryshkov,
eadavis, konrad.dybcio, linux-fsdevel, linux-kernel,
syzkaller-bugs
On 7/26/23 10:03 AM, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Date: Mon Dec 26 04:21:51 2022 +0000
>
> arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> start commit: [unknown]
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
>
> If the result looks correct, please mark the issue as fixed by replying with:
>
> #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
The bisect is very likely to be wrong.
I have a lot of patches to gfs2's quota code in linux-gfs2/bobquota that
I hope to get into the next merge window, but the critical patch has
already been merged. I'm still working on others.
Regards,
Bob Peterson
gfs2 file system
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-07-26 16:14 ` Bob Peterson
0 siblings, 0 replies; 22+ messages in thread
From: Bob Peterson @ 2023-07-26 16:14 UTC (permalink / raw)
To: cluster-devel.redhat.com
On 7/26/23 10:03 AM, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 41a37d157a613444c97e8f71a5fb2a21116b70d7
> Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Date: Mon Dec 26 04:21:51 2022 +0000
>
> arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a80000
> start commit: [unknown]
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/x/.config?x=fe56f7d193926860
> dashboard link: https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209f878c80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=111a48ab480000
>
> If the result looks correct, please mark the issue as fixed by replying with:
>
> #syz fix: arm64: dts: qcom: qcs404: use symbol names for PCIe resets
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
The bisect is very likely to be wrong.
I have a lot of patches to gfs2's quota code in linux-gfs2/bobquota that
I hope to get into the next merge window, but the critical patch has
already been merged. I'm still working on others.
Regards,
Bob Peterson
gfs2 file system
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
2023-07-26 15:45 ` [Cluster-devel] " Dmitry Baryshkov
@ 2023-07-27 1:09 ` Theodore Ts'o
-1 siblings, 0 replies; 22+ messages in thread
From: Theodore Ts'o @ 2023-07-27 1:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Aleksandr Nogikh, syzbot, agruenba, andersson, cluster-devel,
eadavis, konrad.dybcio, linux-fsdevel, linux-kernel, rpeterso,
syzkaller-bugs
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2)
@ 2023-07-27 1:09 ` Theodore Ts'o
0 siblings, 0 replies; 22+ messages in thread
From: Theodore Ts'o @ 2023-07-27 1:09 UTC (permalink / raw)
To: cluster-devel.redhat.com
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-01-30 14:32 ` [Cluster-devel] " Andreas Gruenbacher
(?)
@ 2023-08-20 5:04 ` eadavis
-1 siblings, 0 replies; 22+ messages in thread
From: eadavis @ 2023-08-20 5:04 UTC (permalink / raw)
To: agruenba
Cc: syzbot+3f6a670108ce43356017, eadaivs, syzkaller-bugs,
linux-kernel, cluster-devel
From: eadaivs <eadaivs@sina.com>
Hello Andreas,
On Mon, 30 Jan 2023 15:32:42 +0100 <agruenba@redhat.com> wrote:
> I can see that there is a problem in the gfs2 quota code, but this
> unfortunately doesn't look like an acceptable fix. A better approach
> would be to use proper reference counting for gfs2_quota_data objects.
> In this case, gfs2_quota_sync() is still holding a reference, so the
> underlying object shouldn't be freed.
>
> Fixing this properly will require more than a handful of lines.
Before clearing quota, wait for the qd synchronization operation to end.
Add reference count in gfs2_quota_data and perform qd synchronization
to control whether qd is in use. If so, temporarily clear quota.
Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
Signed-off-by: eadaivs <eadaivs@sina.com>
---
fs/gfs2/incore.h | 1 +
fs/gfs2/quota.c | 16 ++++++++++++----
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h
index c26765080f28..61549bd95b32 100644
--- a/fs/gfs2/incore.h
+++ b/fs/gfs2/incore.h
@@ -463,6 +463,7 @@ struct gfs2_quota_data {
u64 qd_sync_gen;
unsigned long qd_last_warn;
struct rcu_head qd_rcu;
+ unsigned int ref_cnt;
};
enum {
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
index 1ed17226d9ed..dca4be078ce8 100644
--- a/fs/gfs2/quota.c
+++ b/fs/gfs2/quota.c
@@ -478,6 +478,7 @@ static int qd_fish(struct gfs2_sbd *sdp, struct gfs2_quota_data **qdp)
qd_put(qd);
return error;
}
+ WRITE_ONCE(qd->ref_cnt, READ_ONCE(qd->ref_cnt) + 1);
}
*qdp = qd;
@@ -493,6 +494,7 @@ static void qd_unlock(struct gfs2_quota_data *qd)
bh_put(qd);
slot_put(qd);
qd_put(qd);
+ WRITE_ONCE(qd->ref_cnt, READ_ONCE(qd->ref_cnt) - 1);
}
static int qdsb_get(struct gfs2_sbd *sdp, struct kqid qid,
@@ -1422,6 +1424,7 @@ int gfs2_quota_init(struct gfs2_sbd *sdp)
qd->qd_change = qc_change;
qd->qd_slot = slot;
qd->qd_slot_count = 1;
+ WRITE_ONCE(qd->ref_cnt, 0);
spin_lock(&qd_lock);
BUG_ON(test_and_set_bit(slot, sdp->sd_quota_bitmap));
@@ -1454,11 +1457,13 @@ int gfs2_quota_init(struct gfs2_sbd *sdp)
void gfs2_quota_cleanup(struct gfs2_sbd *sdp)
{
struct list_head *head = &sdp->sd_quota_list;
- struct gfs2_quota_data *qd;
+ struct gfs2_quota_data *qd, *safe;
+retry:
spin_lock(&qd_lock);
- while (!list_empty(head)) {
- qd = list_last_entry(head, struct gfs2_quota_data, qd_list);
+ list_for_each_entry_safe(qd, safe, head, qd_list) {
+ if (READ_ONCE(qd->ref_cnt))
+ continue;
list_del(&qd->qd_list);
@@ -1482,7 +1487,10 @@ void gfs2_quota_cleanup(struct gfs2_sbd *sdp)
}
spin_unlock(&qd_lock);
- gfs2_assert_warn(sdp, !atomic_read(&sdp->sd_quota_count));
+ if (atomic_read(&sdp->sd_quota_count)) {
+ schedule_timeout_uninterruptible(HZ);
+ goto retry;
+ }
kvfree(sdp->sd_quota_bitmap);
sdp->sd_quota_bitmap = NULL;
--
2.41.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-01-27 5:10 ` [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync eadavis
@ 2023-08-22 19:32 ` Bob Peterson
2023-08-22 19:32 ` [Cluster-devel] " Bob Peterson
1 sibling, 0 replies; 22+ messages in thread
From: Bob Peterson @ 2023-08-22 19:32 UTC (permalink / raw)
To: eadavis, syzbot+3f6a670108ce43356017
Cc: agruenba, cluster-devel, linux-kernel, syzkaller-bugs
On 1/26/23 11:10 PM, eadavis@sina.com wrote:
> From: Edward Adam Davis <eadavis@sina.com>
>
> [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> [ 81.392343][ T5532] Call Trace:
> [ 81.395654][ T5532] <TASK>
> [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> [ 81.516352][ T5532] do_sync+0x485/0xc80
> [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> [ 81.593753][ T5532] task_work_run+0x243/0x300
> [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> [ 81.712868][ T5532] </TASK>
>
> The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
>
> Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
> Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> ---
> fs/gfs2/quota.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index 1ed1722..4cf66bd 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> qda[x]->qd_sync_gen =
> sdp->sd_quota_sync_gen;
>
> + if (!sdp->sd_quota_bitmap)
> + break;
> +
> for (x = 0; x < num_qd; x++)
> qd_unlock(qda[x]);
> }
Hi Edward,
Can you try to recreate this problem on a newer version of the gfs2 code?
In the linux-gfs2 repository I've got a branch called "bobquota" that
has a bunch of patches related to quota syncing. I don't know if these
will fix your problem, but it's worth trying.
The thing is, the qda array should have been populated by previous
calls, like qd_fish and such, and should be okay to release by
quota_cleanup.
I can tell you this:
In the call trace above, function do_sync tried to lock an inode glock,
which tried to instantiate it, and that caused a withdraw.
The thing is, the only inode glock used by do_sync is for the system
quota inode. If it had a problem instantiating that, your file system is
corrupt and needs to be run through fsck.gfs2. It could indicate a
hardware problem reading the system quota dinode from the storage media.
If possible I'd like to know how you cause this problem to occur. What
were you doing to get this to happen? And how can I recreate it?
GFS2 might have a problem with withdrawing during this sequence, but I
don't think it has much to do with the sd_quota_bitmap.
Regards,
Bob Peterson
GFS2 File System
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
@ 2023-08-22 19:32 ` Bob Peterson
0 siblings, 0 replies; 22+ messages in thread
From: Bob Peterson @ 2023-08-22 19:32 UTC (permalink / raw)
To: eadavis, syzbot+3f6a670108ce43356017
Cc: cluster-devel, syzkaller-bugs, linux-kernel
On 1/26/23 11:10 PM, eadavis@sina.com wrote:
> From: Edward Adam Davis <eadavis@sina.com>
>
> [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> [ 81.392343][ T5532] Call Trace:
> [ 81.395654][ T5532] <TASK>
> [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> [ 81.516352][ T5532] do_sync+0x485/0xc80
> [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> [ 81.593753][ T5532] task_work_run+0x243/0x300
> [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> [ 81.712868][ T5532] </TASK>
>
> The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
>
> Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
> Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> ---
> fs/gfs2/quota.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> index 1ed1722..4cf66bd 100644
> --- a/fs/gfs2/quota.c
> +++ b/fs/gfs2/quota.c
> @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> qda[x]->qd_sync_gen =
> sdp->sd_quota_sync_gen;
>
> + if (!sdp->sd_quota_bitmap)
> + break;
> +
> for (x = 0; x < num_qd; x++)
> qd_unlock(qda[x]);
> }
Hi Edward,
Can you try to recreate this problem on a newer version of the gfs2 code?
In the linux-gfs2 repository I've got a branch called "bobquota" that
has a bunch of patches related to quota syncing. I don't know if these
will fix your problem, but it's worth trying.
The thing is, the qda array should have been populated by previous
calls, like qd_fish and such, and should be okay to release by
quota_cleanup.
I can tell you this:
In the call trace above, function do_sync tried to lock an inode glock,
which tried to instantiate it, and that caused a withdraw.
The thing is, the only inode glock used by do_sync is for the system
quota inode. If it had a problem instantiating that, your file system is
corrupt and needs to be run through fsck.gfs2. It could indicate a
hardware problem reading the system quota dinode from the storage media.
If possible I'd like to know how you cause this problem to occur. What
were you doing to get this to happen? And how can I recreate it?
GFS2 might have a problem with withdrawing during this sequence, but I
don't think it has much to do with the sd_quota_bitmap.
Regards,
Bob Peterson
GFS2 File System
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-08-22 19:32 ` [Cluster-devel] " Bob Peterson
@ 2023-08-23 13:43 ` Andreas Gruenbacher
-1 siblings, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-08-23 13:43 UTC (permalink / raw)
To: Bob Peterson
Cc: eadavis, syzbot+3f6a670108ce43356017, cluster-devel,
linux-kernel, syzkaller-bugs
On Tue, Aug 22, 2023 at 9:32 PM Bob Peterson <rpeterso@redhat.com> wrote:
> On 1/26/23 11:10 PM, eadavis@sina.com wrote:
> > From: Edward Adam Davis <eadavis@sina.com>
> >
> > [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> > [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> > [ 81.392343][ T5532] Call Trace:
> > [ 81.395654][ T5532] <TASK>
> > [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> > [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> > [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> > [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> > [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> > [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> > [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> > [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> > [ 81.516352][ T5532] do_sync+0x485/0xc80
> > [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> > [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> > [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> > [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> > [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> > [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> > [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> > [ 81.593753][ T5532] task_work_run+0x243/0x300
> > [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> > [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> > [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> > [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> > [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> > [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> > [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> > [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> > [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> > [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> > [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> > [ 81.712868][ T5532] </TASK>
> >
> > The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> > This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> > In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> > "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
> >
> > Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
> > Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> > ---
> > fs/gfs2/quota.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> > index 1ed1722..4cf66bd 100644
> > --- a/fs/gfs2/quota.c
> > +++ b/fs/gfs2/quota.c
> > @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> > qda[x]->qd_sync_gen =
> > sdp->sd_quota_sync_gen;
> >
> > + if (!sdp->sd_quota_bitmap)
> > + break;
> > +
> > for (x = 0; x < num_qd; x++)
> > qd_unlock(qda[x]);
> > }
>
> Hi Edward,
>
> Can you try to recreate this problem on a newer version of the gfs2 code?
The problem is that gfs2_quota_sync() is holding references to
gfs2_quota_data objects when the filesystem decides to withdraw. The
withdraw code calls gfs2_quota_cleanup(), which wipes away the
gfs2_quota_data objects that gfs2_quota_sync() is still referencing.
So that reference counting needs to be fixed. Alternatively, if we
could delay the withdraw until the end of gfs2_quota_sync(), we would
be fine as well, but we don't have that kind of mechanism.
> In the linux-gfs2 repository I've got a branch called "bobquota" that
> has a bunch of patches related to quota syncing. I don't know if these
> will fix your problem, but it's worth trying.
That branch doesn't change the reference counting. It doesn't address this bug.
> The thing is, the qda array should have been populated by previous
> calls, like qd_fish and such, and should be okay to release by
> quota_cleanup.
>
> I can tell you this:
>
> In the call trace above, function do_sync tried to lock an inode glock,
> which tried to instantiate it, and that caused a withdraw.
> The thing is, the only inode glock used by do_sync is for the system
> quota inode. If it had a problem instantiating that, your file system is
> corrupt and needs to be run through fsck.gfs2. It could indicate a
> hardware problem reading the system quota dinode from the storage media.
>
> If possible I'd like to know how you cause this problem to occur. What
> were you doing to get this to happen? And how can I recreate it?
It's one of those syzbot bugs, so filesystem fuzzing.
> GFS2 might have a problem with withdrawing during this sequence, but I
> don't think it has much to do with the sd_quota_bitmap.
Yes, I agree.
> Regards,
>
> Bob Peterson
> GFS2 File System
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
@ 2023-08-23 13:43 ` Andreas Gruenbacher
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-08-23 13:43 UTC (permalink / raw)
To: Bob Peterson
Cc: syzbot+3f6a670108ce43356017, cluster-devel, syzkaller-bugs,
linux-kernel, eadavis
On Tue, Aug 22, 2023 at 9:32 PM Bob Peterson <rpeterso@redhat.com> wrote:
> On 1/26/23 11:10 PM, eadavis@sina.com wrote:
> > From: Edward Adam Davis <eadavis@sina.com>
> >
> > [ 81.372851][ T5532] CPU: 1 PID: 5532 Comm: syz-executor.0 Not tainted 6.2.0-rc1-syzkaller-dirty #0
> > [ 81.382080][ T5532] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023
> > [ 81.392343][ T5532] Call Trace:
> > [ 81.395654][ T5532] <TASK>
> > [ 81.398603][ T5532] dump_stack_lvl+0x1b1/0x290
> > [ 81.418421][ T5532] gfs2_assert_warn_i+0x19a/0x2e0
> > [ 81.423480][ T5532] gfs2_quota_cleanup+0x4c6/0x6b0
> > [ 81.428611][ T5532] gfs2_make_fs_ro+0x517/0x610
> > [ 81.457802][ T5532] gfs2_withdraw+0x609/0x1540
> > [ 81.481452][ T5532] gfs2_inode_refresh+0xb2d/0xf60
> > [ 81.506658][ T5532] gfs2_instantiate+0x15e/0x220
> > [ 81.511504][ T5532] gfs2_glock_wait+0x1d9/0x2a0
> > [ 81.516352][ T5532] do_sync+0x485/0xc80
> > [ 81.554943][ T5532] gfs2_quota_sync+0x3da/0x8b0
> > [ 81.559738][ T5532] gfs2_sync_fs+0x49/0xb0
> > [ 81.564063][ T5532] sync_filesystem+0xe8/0x220
> > [ 81.568740][ T5532] generic_shutdown_super+0x6b/0x310
> > [ 81.574112][ T5532] kill_block_super+0x79/0xd0
> > [ 81.578779][ T5532] deactivate_locked_super+0xa7/0xf0
> > [ 81.584064][ T5532] cleanup_mnt+0x494/0x520
> > [ 81.593753][ T5532] task_work_run+0x243/0x300
> > [ 81.608837][ T5532] exit_to_user_mode_loop+0x124/0x150
> > [ 81.614232][ T5532] exit_to_user_mode_prepare+0xb2/0x140
> > [ 81.619820][ T5532] syscall_exit_to_user_mode+0x26/0x60
> > [ 81.625287][ T5532] do_syscall_64+0x49/0xb0
> > [ 81.629710][ T5532] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [ 81.636292][ T5532] RIP: 0033:0x7efdd688d517
> > [ 81.640728][ T5532] Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > [ 81.660550][ T5532] RSP: 002b:00007fff34520ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
> > [ 81.669413][ T5532] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007efdd688d517
> > [ 81.677403][ T5532] RDX: 00007fff34520db9 RSI: 000000000000000a RDI: 00007fff34520db0
> > [ 81.685388][ T5532] RBP: 00007fff34520db0 R08: 00000000ffffffff R09: 00007fff34520b80
> > [ 81.695973][ T5532] R10: 0000555555ca38b3 R11: 0000000000000246 R12: 00007efdd68e6b24
> > [ 81.704152][ T5532] R13: 00007fff34521e70 R14: 0000555555ca3810 R15: 00007fff34521eb0
> > [ 81.712868][ T5532] </TASK>
> >
> > The function "gfs2_quota_cleanup()" may be called in the function "do_sync()",
> > This will cause the qda obtained in the function "qd_check_sync" to be released, resulting in the occurrence of uaf.
> > In order to avoid this uaf, we can increase the judgment of "sdp->sd_quota_bitmap" released in the function
> > "gfs2_quota_cleanup" to confirm that "sdp->sd_quota_list" has been released.
> >
> > Link: https://lore.kernel.org/all/0000000000002b5e2405f14e860f@google.com
> > Reported-and-tested-by: syzbot+3f6a670108ce43356017@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@sina.com>
> > ---
> > fs/gfs2/quota.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
> > index 1ed1722..4cf66bd 100644
> > --- a/fs/gfs2/quota.c
> > +++ b/fs/gfs2/quota.c
> > @@ -1321,6 +1321,9 @@ int gfs2_quota_sync(struct super_block *sb, int type)
> > qda[x]->qd_sync_gen =
> > sdp->sd_quota_sync_gen;
> >
> > + if (!sdp->sd_quota_bitmap)
> > + break;
> > +
> > for (x = 0; x < num_qd; x++)
> > qd_unlock(qda[x]);
> > }
>
> Hi Edward,
>
> Can you try to recreate this problem on a newer version of the gfs2 code?
The problem is that gfs2_quota_sync() is holding references to
gfs2_quota_data objects when the filesystem decides to withdraw. The
withdraw code calls gfs2_quota_cleanup(), which wipes away the
gfs2_quota_data objects that gfs2_quota_sync() is still referencing.
So that reference counting needs to be fixed. Alternatively, if we
could delay the withdraw until the end of gfs2_quota_sync(), we would
be fine as well, but we don't have that kind of mechanism.
> In the linux-gfs2 repository I've got a branch called "bobquota" that
> has a bunch of patches related to quota syncing. I don't know if these
> will fix your problem, but it's worth trying.
That branch doesn't change the reference counting. It doesn't address this bug.
> The thing is, the qda array should have been populated by previous
> calls, like qd_fish and such, and should be okay to release by
> quota_cleanup.
>
> I can tell you this:
>
> In the call trace above, function do_sync tried to lock an inode glock,
> which tried to instantiate it, and that caused a withdraw.
> The thing is, the only inode glock used by do_sync is for the system
> quota inode. If it had a problem instantiating that, your file system is
> corrupt and needs to be run through fsck.gfs2. It could indicate a
> hardware problem reading the system quota dinode from the storage media.
>
> If possible I'd like to know how you cause this problem to occur. What
> were you doing to get this to happen? And how can I recreate it?
It's one of those syzbot bugs, so filesystem fuzzing.
> GFS2 might have a problem with withdrawing during this sequence, but I
> don't think it has much to do with the sd_quota_bitmap.
Yes, I agree.
> Regards,
>
> Bob Peterson
> GFS2 File System
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
2023-08-23 13:43 ` [Cluster-devel] " Andreas Gruenbacher
@ 2023-08-24 21:24 ` Andreas Gruenbacher
-1 siblings, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-08-24 21:24 UTC (permalink / raw)
To: Bob Peterson
Cc: syzbot+3f6a670108ce43356017, cluster-devel, syzkaller-bugs,
linux-kernel, eadavis
I've pushed the fixes for this bug to for-next.
https://lore.kernel.org/cluster-devel/20230824211948.3242607-1-agruenba@redhat.com/
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync
@ 2023-08-24 21:24 ` Andreas Gruenbacher
0 siblings, 0 replies; 22+ messages in thread
From: Andreas Gruenbacher @ 2023-08-24 21:24 UTC (permalink / raw)
To: Bob Peterson
Cc: eadavis, syzbot+3f6a670108ce43356017, cluster-devel,
linux-kernel, syzkaller-bugs
I've pushed the fixes for this bug to for-next.
https://lore.kernel.org/cluster-devel/20230824211948.3242607-1-agruenba@redhat.com/
Thanks,
Andreas
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2023-08-24 21:26 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-02 21:20 [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2) syzbot
2023-01-02 21:20 ` [Cluster-devel] " syzbot
2023-01-27 5:10 ` [Cluster-devel] [PATCH] gfs2: Fix uaf for qda in gfs2_quota_sync eadavis
2023-01-30 14:32 ` Andreas Gruenbacher
2023-01-30 14:32 ` [Cluster-devel] " Andreas Gruenbacher
2023-08-20 5:04 ` eadavis
2023-08-22 19:32 ` Bob Peterson
2023-08-22 19:32 ` [Cluster-devel] " Bob Peterson
2023-08-23 13:43 ` Andreas Gruenbacher
2023-08-23 13:43 ` [Cluster-devel] " Andreas Gruenbacher
2023-08-24 21:24 ` Andreas Gruenbacher
2023-08-24 21:24 ` Andreas Gruenbacher
2023-07-26 15:03 ` [syzbot] [gfs2?] KASAN: use-after-free Read in qd_unlock (2) syzbot
2023-07-26 15:03 ` [Cluster-devel] " syzbot
2023-07-26 15:09 ` Aleksandr Nogikh
2023-07-26 15:09 ` [Cluster-devel] " Aleksandr Nogikh
2023-07-26 15:45 ` Dmitry Baryshkov
2023-07-26 15:45 ` [Cluster-devel] " Dmitry Baryshkov
2023-07-27 1:09 ` Theodore Ts'o
2023-07-27 1:09 ` [Cluster-devel] " Theodore Ts'o
2023-07-26 16:14 ` Bob Peterson
2023-07-26 16:14 ` [Cluster-devel] " Bob Peterson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.