* [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-01-15 9:12 ` syzbot
0 siblings, 0 replies; 21+ messages in thread
From: syzbot @ 2024-01-15 9:12 UTC (permalink / raw
To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14bb9913e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=490fc2f9d4ae426c
dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d9fbcbe80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1422d5ebe80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/51de89c7a81e/disk-052d5343.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7e03b92536a3/vmlinux-052d5343.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3d91124eb5ff/bzImage-052d5343.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f67519526788/mount_0.gz
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/7e871268c842/mount_7.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058
CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x163/0x540 mm/kasan/report.c:488
kasan_report+0x142/0x170 mm/kasan/report.c:601
f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
__do_fault+0x131/0x450 mm/memory.c:4376
do_shared_fault mm/memory.c:4798 [inline]
do_fault mm/memory.c:4872 [inline]
do_pte_missing mm/memory.c:3745 [inline]
handle_pte_fault mm/memory.c:5144 [inline]
__handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285
handle_mm_fault+0x27e/0x770 mm/memory.c:5450
do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]
handle_page_fault arch/x86/mm/fault.c:1507 [inline]
exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
RIP: 0033:0x7f808e742b50
Code: 20 bf 02 00 00 00 e8 9f 24 04 00 48 83 f8 ff 0f 84 08 fa ff ff 48 89 05 e6 65 0c 00 e9 fc f9 ff ff 66 0f 1f 84 00 00 00 00 00 <c7> 04 25 40 00 00 20 66 32 66 73 c6 04 25 44 00 00 20 00 e9 0f fa
RSP: 002b:00007f808e735170 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00007f808e80b6e8 RCX: 00007f808e784fe9
RDX: 86d0f56bab720225 RSI: 0000000000000000 RDI: 00007f808e7355a0
RBP: 00007f808e80b6e0 R08: 0000000000000000 R09: 00007f808e7356c0
R10: 00007f808e80b6e0 R11: 0000000000000246 R12: 00007f808e80b6ec
R13: 0000000000000000 R14: 00007fff41e6fc30 R15: 00007fff41e6fd18
</TASK>
Allocated by task 5058:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x66/0x70 mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc+0x16f/0x340 mm/slub.c:3867
vm_area_alloc+0x24/0x1d0 kernel/fork.c:465
mmap_region+0xbd8/0x1f90 mm/mmap.c:2804
do_mmap+0x76b/0xde0 mm/mmap.c:1379
vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 5064:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:634
poison_slab_object+0xa6/0xe0 mm/kasan/common.c:241
__kasan_slab_free+0x34/0x60 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kmem_cache_free+0x102/0x2a0 mm/slub.c:4363
rcu_do_batch kernel/rcu/tree.c:2158 [inline]
rcu_core+0xad8/0x17c0 kernel/rcu/tree.c:2433
__do_softirq+0x2b8/0x939 kernel/softirq.c:553
Last potentially related work creation:
kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
__kasan_record_aux_stack+0xae/0x100 mm/kasan/generic.c:580
__call_rcu_common kernel/rcu/tree.c:2683 [inline]
call_rcu+0x167/0xa80 kernel/rcu/tree.c:2797
remove_vma mm/mmap.c:148 [inline]
remove_mt mm/mmap.c:2283 [inline]
do_vmi_align_munmap+0x159d/0x1930 mm/mmap.c:2629
do_vmi_munmap+0x24d/0x2d0 mm/mmap.c:2693
mmap_region+0x677/0x1f90 mm/mmap.c:2744
do_mmap+0x76b/0xde0 mm/mmap.c:1379
vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The buggy address belongs to the object at ffff88807bb22660
which belongs to the cache vm_area_struct of size 192
The buggy address is located 32 bytes inside of
freed 192-byte region [ffff88807bb22660, ffff88807bb22720)
The buggy address belongs to the physical page:
page:ffffea0001eec880 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7bb22
flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff8880142a1b40 dead000000000122 0000000000000000
raw: 0000000000000000 00000000800f000f 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 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5039, tgid 5039 (sshd), ts 50202976366, free_ts 44674399535
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x1e6/0x210 mm/page_alloc.c:1533
prep_new_page mm/page_alloc.c:1540 [inline]
get_page_from_freelist+0x33ea/0x3570 mm/page_alloc.c:3311
__alloc_pages+0x255/0x680 mm/page_alloc.c:4567
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page+0x5f/0x160 mm/slub.c:2190
allocate_slab mm/slub.c:2354 [inline]
new_slab+0x84/0x2f0 mm/slub.c:2407
___slab_alloc+0xd17/0x13d0 mm/slub.c:3540
__slab_alloc mm/slub.c:3625 [inline]
__slab_alloc_node mm/slub.c:3678 [inline]
slab_alloc_node mm/slub.c:3850 [inline]
kmem_cache_alloc+0x249/0x340 mm/slub.c:3867
vm_area_dup+0x27/0x280 kernel/fork.c:480
dup_mmap kernel/fork.c:695 [inline]
dup_mm kernel/fork.c:1685 [inline]
copy_mm+0xd90/0x21b0 kernel/fork.c:1734
copy_process+0x1d6f/0x3fb0 kernel/fork.c:2496
kernel_clone+0x222/0x840 kernel/fork.c:2901
__do_sys_clone kernel/fork.c:3044 [inline]
__se_sys_clone kernel/fork.c:3028 [inline]
__x64_sys_clone+0x258/0x2a0 kernel/fork.c:3028
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
page last free pid 5037 tgid 5037 stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1140 [inline]
free_unref_page_prepare+0x959/0xa80 mm/page_alloc.c:2346
free_unref_page+0x37/0x3f0 mm/page_alloc.c:2486
pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
pipe_update_tail fs/pipe.c:234 [inline]
pipe_read+0x6ee/0x13e0 fs/pipe.c:354
call_read_iter include/linux/fs.h:2079 [inline]
new_sync_read fs/read_write.c:395 [inline]
vfs_read+0x662/0x900 fs/read_write.c:476
ksys_read+0x1a0/0x2c0 fs/read_write.c:619
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Memory state around the buggy address:
ffff88807bb22580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88807bb22600: 00 00 fc fc fc fc fc fc fc fc fc fc fa fb fb fb
>ffff88807bb22680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88807bb22700: fb fb fb fb fc fc fc fc fc fc fc fc fc fc 00 00
ffff88807bb22780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
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.
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-01-15 9:12 ` syzbot
0 siblings, 0 replies; 21+ messages in thread
From: syzbot @ 2024-01-15 9:12 UTC (permalink / raw
To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14bb9913e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=490fc2f9d4ae426c
dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d9fbcbe80000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1422d5ebe80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/51de89c7a81e/disk-052d5343.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7e03b92536a3/vmlinux-052d5343.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3d91124eb5ff/bzImage-052d5343.xz
mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f67519526788/mount_0.gz
mounted in repro #2: https://storage.googleapis.com/syzbot-assets/7e871268c842/mount_7.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058
CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x163/0x540 mm/kasan/report.c:488
kasan_report+0x142/0x170 mm/kasan/report.c:601
f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
__do_fault+0x131/0x450 mm/memory.c:4376
do_shared_fault mm/memory.c:4798 [inline]
do_fault mm/memory.c:4872 [inline]
do_pte_missing mm/memory.c:3745 [inline]
handle_pte_fault mm/memory.c:5144 [inline]
__handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285
handle_mm_fault+0x27e/0x770 mm/memory.c:5450
do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]
handle_page_fault arch/x86/mm/fault.c:1507 [inline]
exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
RIP: 0033:0x7f808e742b50
Code: 20 bf 02 00 00 00 e8 9f 24 04 00 48 83 f8 ff 0f 84 08 fa ff ff 48 89 05 e6 65 0c 00 e9 fc f9 ff ff 66 0f 1f 84 00 00 00 00 00 <c7> 04 25 40 00 00 20 66 32 66 73 c6 04 25 44 00 00 20 00 e9 0f fa
RSP: 002b:00007f808e735170 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00007f808e80b6e8 RCX: 00007f808e784fe9
RDX: 86d0f56bab720225 RSI: 0000000000000000 RDI: 00007f808e7355a0
RBP: 00007f808e80b6e0 R08: 0000000000000000 R09: 00007f808e7356c0
R10: 00007f808e80b6e0 R11: 0000000000000246 R12: 00007f808e80b6ec
R13: 0000000000000000 R14: 00007fff41e6fc30 R15: 00007fff41e6fd18
</TASK>
Allocated by task 5058:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:314 [inline]
__kasan_slab_alloc+0x66/0x70 mm/kasan/common.c:340
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3813 [inline]
slab_alloc_node mm/slub.c:3860 [inline]
kmem_cache_alloc+0x16f/0x340 mm/slub.c:3867
vm_area_alloc+0x24/0x1d0 kernel/fork.c:465
mmap_region+0xbd8/0x1f90 mm/mmap.c:2804
do_mmap+0x76b/0xde0 mm/mmap.c:1379
vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 5064:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:634
poison_slab_object+0xa6/0xe0 mm/kasan/common.c:241
__kasan_slab_free+0x34/0x60 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kmem_cache_free+0x102/0x2a0 mm/slub.c:4363
rcu_do_batch kernel/rcu/tree.c:2158 [inline]
rcu_core+0xad8/0x17c0 kernel/rcu/tree.c:2433
__do_softirq+0x2b8/0x939 kernel/softirq.c:553
Last potentially related work creation:
kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
__kasan_record_aux_stack+0xae/0x100 mm/kasan/generic.c:580
__call_rcu_common kernel/rcu/tree.c:2683 [inline]
call_rcu+0x167/0xa80 kernel/rcu/tree.c:2797
remove_vma mm/mmap.c:148 [inline]
remove_mt mm/mmap.c:2283 [inline]
do_vmi_align_munmap+0x159d/0x1930 mm/mmap.c:2629
do_vmi_munmap+0x24d/0x2d0 mm/mmap.c:2693
mmap_region+0x677/0x1f90 mm/mmap.c:2744
do_mmap+0x76b/0xde0 mm/mmap.c:1379
vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
The buggy address belongs to the object at ffff88807bb22660
which belongs to the cache vm_area_struct of size 192
The buggy address is located 32 bytes inside of
freed 192-byte region [ffff88807bb22660, ffff88807bb22720)
The buggy address belongs to the physical page:
page:ffffea0001eec880 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7bb22
flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff8880142a1b40 dead000000000122 0000000000000000
raw: 0000000000000000 00000000800f000f 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 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5039, tgid 5039 (sshd), ts 50202976366, free_ts 44674399535
set_page_owner include/linux/page_owner.h:31 [inline]
post_alloc_hook+0x1e6/0x210 mm/page_alloc.c:1533
prep_new_page mm/page_alloc.c:1540 [inline]
get_page_from_freelist+0x33ea/0x3570 mm/page_alloc.c:3311
__alloc_pages+0x255/0x680 mm/page_alloc.c:4567
__alloc_pages_node include/linux/gfp.h:238 [inline]
alloc_pages_node include/linux/gfp.h:261 [inline]
alloc_slab_page+0x5f/0x160 mm/slub.c:2190
allocate_slab mm/slub.c:2354 [inline]
new_slab+0x84/0x2f0 mm/slub.c:2407
___slab_alloc+0xd17/0x13d0 mm/slub.c:3540
__slab_alloc mm/slub.c:3625 [inline]
__slab_alloc_node mm/slub.c:3678 [inline]
slab_alloc_node mm/slub.c:3850 [inline]
kmem_cache_alloc+0x249/0x340 mm/slub.c:3867
vm_area_dup+0x27/0x280 kernel/fork.c:480
dup_mmap kernel/fork.c:695 [inline]
dup_mm kernel/fork.c:1685 [inline]
copy_mm+0xd90/0x21b0 kernel/fork.c:1734
copy_process+0x1d6f/0x3fb0 kernel/fork.c:2496
kernel_clone+0x222/0x840 kernel/fork.c:2901
__do_sys_clone kernel/fork.c:3044 [inline]
__se_sys_clone kernel/fork.c:3028 [inline]
__x64_sys_clone+0x258/0x2a0 kernel/fork.c:3028
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
page last free pid 5037 tgid 5037 stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1140 [inline]
free_unref_page_prepare+0x959/0xa80 mm/page_alloc.c:2346
free_unref_page+0x37/0x3f0 mm/page_alloc.c:2486
pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
pipe_update_tail fs/pipe.c:234 [inline]
pipe_read+0x6ee/0x13e0 fs/pipe.c:354
call_read_iter include/linux/fs.h:2079 [inline]
new_sync_read fs/read_write.c:395 [inline]
vfs_read+0x662/0x900 fs/read_write.c:476
ksys_read+0x1a0/0x2c0 fs/read_write.c:619
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Memory state around the buggy address:
ffff88807bb22580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88807bb22600: 00 00 fc fc fc fc fc fc fc fc fc fc fa fb fb fb
>ffff88807bb22680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88807bb22700: fb fb fb fb fc fc fc fc fc fc fc fc fc fc 00 00
ffff88807bb22780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
---
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.
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
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-01-15 9:12 ` [f2fs-dev] " syzbot
(?)
@ 2024-01-15 12:05 ` Hillf Danton
2024-01-15 19:17 ` syzbot
2024-03-12 1:33 ` Ed Tsai (蔡宗軒)
-1 siblings, 2 replies; 21+ messages in thread
From: Hillf Danton @ 2024-01-15 12:05 UTC (permalink / raw
To: syzbot; +Cc: linux-kernel, syzkaller-bugs
On Mon, 15 Jan 2024 01:12:17 -0800
> HEAD commit: 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
> git tree: upstream
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1422d5ebe80000
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
--- x/fs/f2fs/file.c
+++ y/fs/f2fs/file.c
@@ -39,6 +39,7 @@
static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
{
struct inode *inode = file_inode(vmf->vma->vm_file);
+ vm_flags_t flags = vmf->vma->vm_flags;
vm_fault_t ret;
ret = filemap_fault(vmf);
@@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
f2fs_update_iostat(F2FS_I_SB(inode), inode,
APP_MAPPED_READ_IO, F2FS_BLKSIZE);
- trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma->vm_flags, ret);
+ trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
return ret;
}
--
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-01-15 12:05 ` Hillf Danton
@ 2024-01-15 19:17 ` syzbot
2024-03-12 1:33 ` Ed Tsai (蔡宗軒)
1 sibling, 0 replies; 21+ messages in thread
From: syzbot @ 2024-01-15 19:17 UTC (permalink / raw
To: hdanton, linux-kernel, syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
Tested on:
commit: 052d5343 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=105a1a0be80000
kernel config: https://syzkaller.appspot.com/x/.config?x=490fc2f9d4ae426c
dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=14a249b9e80000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-01-15 12:05 ` Hillf Danton
2024-01-15 19:17 ` syzbot
@ 2024-03-12 1:33 ` Ed Tsai (蔡宗軒)
2024-03-13 1:31 ` [f2fs-dev] " Jaegeuk Kim
[not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>
1 sibling, 2 replies; 21+ messages in thread
From: Ed Tsai (蔡宗軒) @ 2024-03-12 1:33 UTC (permalink / raw
To: jaegeuk@kernel.org, hdanton@sina.com
Cc: Light Hsieh (謝明燈),
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Freddy Hsin (辛恒豐),
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
On Mon, 2024-01-15 at 20:05 +0800, Hillf Danton wrote:
>
> ...
>
> --- x/fs/f2fs/file.c
> +++ y/fs/f2fs/file.c
> @@ -39,6 +39,7 @@
> static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
> {
> struct inode *inode = file_inode(vmf->vma->vm_file);
> + vm_flags_t flags = vmf->vma->vm_flags;
> vm_fault_t ret;
>
> ret = filemap_fault(vmf);
> @@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
> f2fs_update_iostat(F2FS_I_SB(inode), inode,
> APP_MAPPED_READ_IO,
> F2FS_BLKSIZE);
>
> - trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma-
> >vm_flags, ret);
> + trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
>
> return ret;
> }
> --
Hi Jaegeuk,
We recently encountered this slabe-use-after-free issue in KASAN as
well. Could you please review the patch above and merge it into f2fs?
Best,
Ed
==================================================================
[29195.369964][T31720] BUG: KASAN: slab-use-after-free in
f2fs_filemap_fault+0x50/0xe0
[29195.370971][T31720] Read at addr f7ffff80454ebde0 by task AsyncTask
#11/31720
[29195.371881][T31720] Pointer tag: [f7], memory tag: [f1]
[29195.372549][T31720]
[29195.372838][T31720] CPU: 2 PID: 31720 Comm: AsyncTask #11 Tainted:
G W OE 6.6.17-android15-0-gcb5ba718a525 #1
[29195.374862][T31720] Call trace:
[29195.375268][T31720] dump_backtrace+0xec/0x138
[29195.375848][T31720] show_stack+0x18/0x24
[29195.376365][T31720] dump_stack_lvl+0x50/0x6c
[29195.376943][T31720] print_report+0x1b0/0x714
[29195.377520][T31720] kasan_report+0xc4/0x124
[29195.378076][T31720] __do_kernel_fault+0xb8/0x26c
[29195.378694][T31720] do_bad_area+0x30/0xdc
[29195.379226][T31720] do_tag_check_fault+0x20/0x34
[29195.379834][T31720] do_mem_abort+0x58/0x104
[29195.380388][T31720] el1_abort+0x3c/0x5c
[29195.380899][T31720] el1h_64_sync_handler+0x54/0x90
[29195.381529][T31720] el1h_64_sync+0x68/0x6c
[29195.382069][T31720] f2fs_filemap_fault+0x50/0xe0
[29195.382678][T31720] __do_fault+0xc8/0xfc
[29195.383209][T31720] handle_mm_fault+0xb44/0x10c4
[29195.383816][T31720] do_page_fault+0x294/0x48c
[29195.384395][T31720] do_translation_fault+0x38/0x54
[29195.385023][T31720] do_mem_abort+0x58/0x104
[29195.385577][T31720] el0_da+0x44/0x78
[29195.386057][T31720] el0t_64_sync_handler+0x98/0xbc
[29195.386688][T31720] el0t_64_sync+0x1a8/0x1ac
[29195.387249][T31720]
[29195.387534][T31720] Allocated by task 14784:
[29195.388085][T31720] kasan_save_stack+0x40/0x70
[29195.388672][T31720] save_stack_info+0x34/0x128
[29195.389259][T31720] kasan_save_alloc_info+0x14/0x20
[29195.389901][T31720] __kasan_slab_alloc+0x168/0x174
[29195.390530][T31720] slab_post_alloc_hook+0x88/0x3a4
[29195.391168][T31720] kmem_cache_alloc+0x18c/0x2c8
[29195.391771][T31720] vm_area_alloc+0x2c/0xe8
[29195.392327][T31720] mmap_region+0x440/0xa94
[29195.392888][T31720] do_mmap+0x3d0/0x524
[29195.393399][T31720] vm_mmap_pgoff+0x1a0/0x1f8
[29195.393980][T31720] ksys_mmap_pgoff+0x78/0xf4
[29195.394557][T31720] __arm64_sys_mmap+0x34/0x44
[29195.395138][T31720] invoke_syscall+0x58/0x114
[29195.395727][T31720] el0_svc_common+0x80/0xe0
[29195.396292][T31720] do_el0_svc+0x1c/0x28
[29195.396812][T31720] el0_svc+0x38/0x68
[29195.397302][T31720] el0t_64_sync_handler+0x68/0xbc
[29195.397932][T31720] el0t_64_sync+0x1a8/0x1ac
[29195.398492][T31720]
[29195.398778][T31720] Freed by task 0:
[29195.399240][T31720] kasan_save_stack+0x40/0x70
[29195.399825][T31720] save_stack_info+0x34/0x128
[29195.400412][T31720] kasan_save_free_info+0x18/0x28
[29195.401043][T31720] ____kasan_slab_free+0x254/0x25c
[29195.401682][T31720] __kasan_slab_free+0x10/0x20
[29195.402278][T31720] slab_free_freelist_hook+0x174/0x1e0
[29195.402961][T31720] kmem_cache_free+0xc4/0x348
[29195.403544][T31720] __vm_area_free+0x84/0xa4
[29195.404103][T31720] vm_area_free_rcu_cb+0x10/0x20
[29195.404719][T31720] rcu_do_batch+0x214/0x720
[29195.405284][T31720] rcu_core+0x1b0/0x408
[29195.405800][T31720] rcu_core_si+0x10/0x20
[29195.406348][T31720] __do_softirq+0x120/0x3f4
[29195.406907][T31720]
[29195.407191][T31720] The buggy address belongs to the object at
ffffff80454ebdc0
[29195.407191][T31720] which belongs to the cache vm_area_struct of
size 176
[29195.408978][T31720] The buggy address is located 32 bytes inside of
[29195.408978][T31720] 176-byte region [ffffff80454ebdc0,
ffffff80454ebe70)
[29195.410625][T31720]
[29195.410911][T31720] The buggy address belongs to the physical page:
[29195.411709][T31720] page:0000000058f0f2f1 refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0xc54eb
[29195.412980][T31720] anon flags:
0x4000000000000800(slab|zone=1|kasantag=0x0)
[29195.413880][T31720] page_type: 0xffffffff()
[29195.414418][T31720] raw: 4000000000000800 f6ffff8002904500
fffffffe076fc8c0 dead000000000007
[29195.415488][T31720] raw: 0000000000000000 0000000000170017
00000001ffffffff 0000000000000000
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-03-12 1:33 ` Ed Tsai (蔡宗軒)
@ 2024-03-13 1:31 ` Jaegeuk Kim
[not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>
1 sibling, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-13 1:31 UTC (permalink / raw
To: Ed Tsai (蔡宗軒)
Cc: hdanton@sina.com, Light Hsieh (謝明燈),
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
Freddy Hsin (辛恒豐),
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
On 03/12, Ed Tsai (蔡宗軒) wrote:
> On Mon, 2024-01-15 at 20:05 +0800, Hillf Danton wrote:
> >
> > ...
> >
> > --- x/fs/f2fs/file.c
> > +++ y/fs/f2fs/file.c
> > @@ -39,6 +39,7 @@
> > static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
> > {
> > struct inode *inode = file_inode(vmf->vma->vm_file);
> > + vm_flags_t flags = vmf->vma->vm_flags;
> > vm_fault_t ret;
> >
> > ret = filemap_fault(vmf);
> > @@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
> > f2fs_update_iostat(F2FS_I_SB(inode), inode,
> > APP_MAPPED_READ_IO,
> > F2FS_BLKSIZE);
> >
> > - trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma-
> > >vm_flags, ret);
> > + trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
> >
> > return ret;
> > }
> > --
>
> Hi Jaegeuk,
>
> We recently encountered this slabe-use-after-free issue in KASAN as
> well. Could you please review the patch above and merge it into f2fs?
Where is the patch?
>
> Best,
> Ed
>
> ==================================================================
> [29195.369964][T31720] BUG: KASAN: slab-use-after-free in
> f2fs_filemap_fault+0x50/0xe0
> [29195.370971][T31720] Read at addr f7ffff80454ebde0 by task AsyncTask
> #11/31720
> [29195.371881][T31720] Pointer tag: [f7], memory tag: [f1]
> [29195.372549][T31720]
> [29195.372838][T31720] CPU: 2 PID: 31720 Comm: AsyncTask #11 Tainted:
> G W OE 6.6.17-android15-0-gcb5ba718a525 #1
> [29195.374862][T31720] Call trace:
> [29195.375268][T31720] dump_backtrace+0xec/0x138
> [29195.375848][T31720] show_stack+0x18/0x24
> [29195.376365][T31720] dump_stack_lvl+0x50/0x6c
> [29195.376943][T31720] print_report+0x1b0/0x714
> [29195.377520][T31720] kasan_report+0xc4/0x124
> [29195.378076][T31720] __do_kernel_fault+0xb8/0x26c
> [29195.378694][T31720] do_bad_area+0x30/0xdc
> [29195.379226][T31720] do_tag_check_fault+0x20/0x34
> [29195.379834][T31720] do_mem_abort+0x58/0x104
> [29195.380388][T31720] el1_abort+0x3c/0x5c
> [29195.380899][T31720] el1h_64_sync_handler+0x54/0x90
> [29195.381529][T31720] el1h_64_sync+0x68/0x6c
> [29195.382069][T31720] f2fs_filemap_fault+0x50/0xe0
> [29195.382678][T31720] __do_fault+0xc8/0xfc
> [29195.383209][T31720] handle_mm_fault+0xb44/0x10c4
> [29195.383816][T31720] do_page_fault+0x294/0x48c
> [29195.384395][T31720] do_translation_fault+0x38/0x54
> [29195.385023][T31720] do_mem_abort+0x58/0x104
> [29195.385577][T31720] el0_da+0x44/0x78
> [29195.386057][T31720] el0t_64_sync_handler+0x98/0xbc
> [29195.386688][T31720] el0t_64_sync+0x1a8/0x1ac
> [29195.387249][T31720]
> [29195.387534][T31720] Allocated by task 14784:
> [29195.388085][T31720] kasan_save_stack+0x40/0x70
> [29195.388672][T31720] save_stack_info+0x34/0x128
> [29195.389259][T31720] kasan_save_alloc_info+0x14/0x20
> [29195.389901][T31720] __kasan_slab_alloc+0x168/0x174
> [29195.390530][T31720] slab_post_alloc_hook+0x88/0x3a4
> [29195.391168][T31720] kmem_cache_alloc+0x18c/0x2c8
> [29195.391771][T31720] vm_area_alloc+0x2c/0xe8
> [29195.392327][T31720] mmap_region+0x440/0xa94
> [29195.392888][T31720] do_mmap+0x3d0/0x524
> [29195.393399][T31720] vm_mmap_pgoff+0x1a0/0x1f8
> [29195.393980][T31720] ksys_mmap_pgoff+0x78/0xf4
> [29195.394557][T31720] __arm64_sys_mmap+0x34/0x44
> [29195.395138][T31720] invoke_syscall+0x58/0x114
> [29195.395727][T31720] el0_svc_common+0x80/0xe0
> [29195.396292][T31720] do_el0_svc+0x1c/0x28
> [29195.396812][T31720] el0_svc+0x38/0x68
> [29195.397302][T31720] el0t_64_sync_handler+0x68/0xbc
> [29195.397932][T31720] el0t_64_sync+0x1a8/0x1ac
> [29195.398492][T31720]
> [29195.398778][T31720] Freed by task 0:
> [29195.399240][T31720] kasan_save_stack+0x40/0x70
> [29195.399825][T31720] save_stack_info+0x34/0x128
> [29195.400412][T31720] kasan_save_free_info+0x18/0x28
> [29195.401043][T31720] ____kasan_slab_free+0x254/0x25c
> [29195.401682][T31720] __kasan_slab_free+0x10/0x20
> [29195.402278][T31720] slab_free_freelist_hook+0x174/0x1e0
> [29195.402961][T31720] kmem_cache_free+0xc4/0x348
> [29195.403544][T31720] __vm_area_free+0x84/0xa4
> [29195.404103][T31720] vm_area_free_rcu_cb+0x10/0x20
> [29195.404719][T31720] rcu_do_batch+0x214/0x720
> [29195.405284][T31720] rcu_core+0x1b0/0x408
> [29195.405800][T31720] rcu_core_si+0x10/0x20
> [29195.406348][T31720] __do_softirq+0x120/0x3f4
> [29195.406907][T31720]
> [29195.407191][T31720] The buggy address belongs to the object at
> ffffff80454ebdc0
> [29195.407191][T31720] which belongs to the cache vm_area_struct of
> size 176
> [29195.408978][T31720] The buggy address is located 32 bytes inside of
> [29195.408978][T31720] 176-byte region [ffffff80454ebdc0,
> ffffff80454ebe70)
> [29195.410625][T31720]
> [29195.410911][T31720] The buggy address belongs to the physical page:
> [29195.411709][T31720] page:0000000058f0f2f1 refcount:1 mapcount:0
> mapping:0000000000000000 index:0x0 pfn:0xc54eb
> [29195.412980][T31720] anon flags:
> 0x4000000000000800(slab|zone=1|kasantag=0x0)
> [29195.413880][T31720] page_type: 0xffffffff()
> [29195.414418][T31720] raw: 4000000000000800 f6ffff8002904500
> fffffffe076fc8c0 dead000000000007
> [29195.415488][T31720] raw: 0000000000000000 0000000000170017
> 00000001ffffffff 0000000000000000
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-03-13 1:31 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-13 1:31 UTC (permalink / raw
To: Ed Tsai (蔡宗軒)
Cc: hdanton@sina.com, Chun-Hung Wu (巫駿宏),
linux-kernel@vger.kernel.org,
Light Hsieh (謝明燈),
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Freddy Hsin (辛恒豐)
On 03/12, Ed Tsai (蔡宗軒) wrote:
> On Mon, 2024-01-15 at 20:05 +0800, Hillf Danton wrote:
> >
> > ...
> >
> > --- x/fs/f2fs/file.c
> > +++ y/fs/f2fs/file.c
> > @@ -39,6 +39,7 @@
> > static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
> > {
> > struct inode *inode = file_inode(vmf->vma->vm_file);
> > + vm_flags_t flags = vmf->vma->vm_flags;
> > vm_fault_t ret;
> >
> > ret = filemap_fault(vmf);
> > @@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
> > f2fs_update_iostat(F2FS_I_SB(inode), inode,
> > APP_MAPPED_READ_IO,
> > F2FS_BLKSIZE);
> >
> > - trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma-
> > >vm_flags, ret);
> > + trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
> >
> > return ret;
> > }
> > --
>
> Hi Jaegeuk,
>
> We recently encountered this slabe-use-after-free issue in KASAN as
> well. Could you please review the patch above and merge it into f2fs?
Where is the patch?
>
> Best,
> Ed
>
> ==================================================================
> [29195.369964][T31720] BUG: KASAN: slab-use-after-free in
> f2fs_filemap_fault+0x50/0xe0
> [29195.370971][T31720] Read at addr f7ffff80454ebde0 by task AsyncTask
> #11/31720
> [29195.371881][T31720] Pointer tag: [f7], memory tag: [f1]
> [29195.372549][T31720]
> [29195.372838][T31720] CPU: 2 PID: 31720 Comm: AsyncTask #11 Tainted:
> G W OE 6.6.17-android15-0-gcb5ba718a525 #1
> [29195.374862][T31720] Call trace:
> [29195.375268][T31720] dump_backtrace+0xec/0x138
> [29195.375848][T31720] show_stack+0x18/0x24
> [29195.376365][T31720] dump_stack_lvl+0x50/0x6c
> [29195.376943][T31720] print_report+0x1b0/0x714
> [29195.377520][T31720] kasan_report+0xc4/0x124
> [29195.378076][T31720] __do_kernel_fault+0xb8/0x26c
> [29195.378694][T31720] do_bad_area+0x30/0xdc
> [29195.379226][T31720] do_tag_check_fault+0x20/0x34
> [29195.379834][T31720] do_mem_abort+0x58/0x104
> [29195.380388][T31720] el1_abort+0x3c/0x5c
> [29195.380899][T31720] el1h_64_sync_handler+0x54/0x90
> [29195.381529][T31720] el1h_64_sync+0x68/0x6c
> [29195.382069][T31720] f2fs_filemap_fault+0x50/0xe0
> [29195.382678][T31720] __do_fault+0xc8/0xfc
> [29195.383209][T31720] handle_mm_fault+0xb44/0x10c4
> [29195.383816][T31720] do_page_fault+0x294/0x48c
> [29195.384395][T31720] do_translation_fault+0x38/0x54
> [29195.385023][T31720] do_mem_abort+0x58/0x104
> [29195.385577][T31720] el0_da+0x44/0x78
> [29195.386057][T31720] el0t_64_sync_handler+0x98/0xbc
> [29195.386688][T31720] el0t_64_sync+0x1a8/0x1ac
> [29195.387249][T31720]
> [29195.387534][T31720] Allocated by task 14784:
> [29195.388085][T31720] kasan_save_stack+0x40/0x70
> [29195.388672][T31720] save_stack_info+0x34/0x128
> [29195.389259][T31720] kasan_save_alloc_info+0x14/0x20
> [29195.389901][T31720] __kasan_slab_alloc+0x168/0x174
> [29195.390530][T31720] slab_post_alloc_hook+0x88/0x3a4
> [29195.391168][T31720] kmem_cache_alloc+0x18c/0x2c8
> [29195.391771][T31720] vm_area_alloc+0x2c/0xe8
> [29195.392327][T31720] mmap_region+0x440/0xa94
> [29195.392888][T31720] do_mmap+0x3d0/0x524
> [29195.393399][T31720] vm_mmap_pgoff+0x1a0/0x1f8
> [29195.393980][T31720] ksys_mmap_pgoff+0x78/0xf4
> [29195.394557][T31720] __arm64_sys_mmap+0x34/0x44
> [29195.395138][T31720] invoke_syscall+0x58/0x114
> [29195.395727][T31720] el0_svc_common+0x80/0xe0
> [29195.396292][T31720] do_el0_svc+0x1c/0x28
> [29195.396812][T31720] el0_svc+0x38/0x68
> [29195.397302][T31720] el0t_64_sync_handler+0x68/0xbc
> [29195.397932][T31720] el0t_64_sync+0x1a8/0x1ac
> [29195.398492][T31720]
> [29195.398778][T31720] Freed by task 0:
> [29195.399240][T31720] kasan_save_stack+0x40/0x70
> [29195.399825][T31720] save_stack_info+0x34/0x128
> [29195.400412][T31720] kasan_save_free_info+0x18/0x28
> [29195.401043][T31720] ____kasan_slab_free+0x254/0x25c
> [29195.401682][T31720] __kasan_slab_free+0x10/0x20
> [29195.402278][T31720] slab_free_freelist_hook+0x174/0x1e0
> [29195.402961][T31720] kmem_cache_free+0xc4/0x348
> [29195.403544][T31720] __vm_area_free+0x84/0xa4
> [29195.404103][T31720] vm_area_free_rcu_cb+0x10/0x20
> [29195.404719][T31720] rcu_do_batch+0x214/0x720
> [29195.405284][T31720] rcu_core+0x1b0/0x408
> [29195.405800][T31720] rcu_core_si+0x10/0x20
> [29195.406348][T31720] __do_softirq+0x120/0x3f4
> [29195.406907][T31720]
> [29195.407191][T31720] The buggy address belongs to the object at
> ffffff80454ebdc0
> [29195.407191][T31720] which belongs to the cache vm_area_struct of
> size 176
> [29195.408978][T31720] The buggy address is located 32 bytes inside of
> [29195.408978][T31720] 176-byte region [ffffff80454ebdc0,
> ffffff80454ebe70)
> [29195.410625][T31720]
> [29195.410911][T31720] The buggy address belongs to the physical page:
> [29195.411709][T31720] page:0000000058f0f2f1 refcount:1 mapcount:0
> mapping:0000000000000000 index:0x0 pfn:0xc54eb
> [29195.412980][T31720] anon flags:
> 0x4000000000000800(slab|zone=1|kasantag=0x0)
> [29195.413880][T31720] page_type: 0xffffffff()
> [29195.414418][T31720] raw: 4000000000000800 f6ffff8002904500
> fffffffe076fc8c0 dead000000000007
> [29195.415488][T31720] raw: 0000000000000000 0000000000170017
> 00000001ffffffff 0000000000000000
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-01-15 9:12 ` [f2fs-dev] " syzbot
@ 2024-03-13 14:32 ` Chao Yu
-1 siblings, 0 replies; 21+ messages in thread
From: Chao Yu @ 2024-03-13 14:32 UTC (permalink / raw
To: syzbot, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
#syz test git://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
On 2024/1/15 17:12, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14bb9913e80000
> kernel config: https://syzkaller.appspot.com/x/.config?x=490fc2f9d4ae426c
> dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d9fbcbe80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1422d5ebe80000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/51de89c7a81e/disk-052d5343.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7e03b92536a3/vmlinux-052d5343.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3d91124eb5ff/bzImage-052d5343.xz
> mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f67519526788/mount_0.gz
> mounted in repro #2: https://storage.googleapis.com/syzbot-assets/7e871268c842/mount_7.gz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
> Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058
>
> CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
> print_address_description mm/kasan/report.c:377 [inline]
> print_report+0x163/0x540 mm/kasan/report.c:488
> kasan_report+0x142/0x170 mm/kasan/report.c:601
> f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
> __do_fault+0x131/0x450 mm/memory.c:4376
> do_shared_fault mm/memory.c:4798 [inline]
> do_fault mm/memory.c:4872 [inline]
> do_pte_missing mm/memory.c:3745 [inline]
> handle_pte_fault mm/memory.c:5144 [inline]
> __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285
> handle_mm_fault+0x27e/0x770 mm/memory.c:5450
> do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]
> handle_page_fault arch/x86/mm/fault.c:1507 [inline]
> exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563
> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
> RIP: 0033:0x7f808e742b50
> Code: 20 bf 02 00 00 00 e8 9f 24 04 00 48 83 f8 ff 0f 84 08 fa ff ff 48 89 05 e6 65 0c 00 e9 fc f9 ff ff 66 0f 1f 84 00 00 00 00 00 <c7> 04 25 40 00 00 20 66 32 66 73 c6 04 25 44 00 00 20 00 e9 0f fa
> RSP: 002b:00007f808e735170 EFLAGS: 00010246
>
> RAX: 0000000000000000 RBX: 00007f808e80b6e8 RCX: 00007f808e784fe9
> RDX: 86d0f56bab720225 RSI: 0000000000000000 RDI: 00007f808e7355a0
> RBP: 00007f808e80b6e0 R08: 0000000000000000 R09: 00007f808e7356c0
> R10: 00007f808e80b6e0 R11: 0000000000000246 R12: 00007f808e80b6ec
> R13: 0000000000000000 R14: 00007fff41e6fc30 R15: 00007fff41e6fd18
> </TASK>
>
> Allocated by task 5058:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
> unpoison_slab_object mm/kasan/common.c:314 [inline]
> __kasan_slab_alloc+0x66/0x70 mm/kasan/common.c:340
> kasan_slab_alloc include/linux/kasan.h:201 [inline]
> slab_post_alloc_hook mm/slub.c:3813 [inline]
> slab_alloc_node mm/slub.c:3860 [inline]
> kmem_cache_alloc+0x16f/0x340 mm/slub.c:3867
> vm_area_alloc+0x24/0x1d0 kernel/fork.c:465
> mmap_region+0xbd8/0x1f90 mm/mmap.c:2804
> do_mmap+0x76b/0xde0 mm/mmap.c:1379
> vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
> ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> Freed by task 5064:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
> kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:634
> poison_slab_object+0xa6/0xe0 mm/kasan/common.c:241
> __kasan_slab_free+0x34/0x60 mm/kasan/common.c:257
> kasan_slab_free include/linux/kasan.h:184 [inline]
> slab_free_hook mm/slub.c:2121 [inline]
> slab_free mm/slub.c:4299 [inline]
> kmem_cache_free+0x102/0x2a0 mm/slub.c:4363
> rcu_do_batch kernel/rcu/tree.c:2158 [inline]
> rcu_core+0xad8/0x17c0 kernel/rcu/tree.c:2433
> __do_softirq+0x2b8/0x939 kernel/softirq.c:553
>
> Last potentially related work creation:
> kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
> __kasan_record_aux_stack+0xae/0x100 mm/kasan/generic.c:580
> __call_rcu_common kernel/rcu/tree.c:2683 [inline]
> call_rcu+0x167/0xa80 kernel/rcu/tree.c:2797
> remove_vma mm/mmap.c:148 [inline]
> remove_mt mm/mmap.c:2283 [inline]
> do_vmi_align_munmap+0x159d/0x1930 mm/mmap.c:2629
> do_vmi_munmap+0x24d/0x2d0 mm/mmap.c:2693
> mmap_region+0x677/0x1f90 mm/mmap.c:2744
> do_mmap+0x76b/0xde0 mm/mmap.c:1379
> vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
> ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> The buggy address belongs to the object at ffff88807bb22660
> which belongs to the cache vm_area_struct of size 192
> The buggy address is located 32 bytes inside of
> freed 192-byte region [ffff88807bb22660, ffff88807bb22720)
>
> The buggy address belongs to the physical page:
> page:ffffea0001eec880 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7bb22
> flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
> page_type: 0xffffffff()
> raw: 00fff00000000800 ffff8880142a1b40 dead000000000122 0000000000000000
> raw: 0000000000000000 00000000800f000f 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 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5039, tgid 5039 (sshd), ts 50202976366, free_ts 44674399535
> set_page_owner include/linux/page_owner.h:31 [inline]
> post_alloc_hook+0x1e6/0x210 mm/page_alloc.c:1533
> prep_new_page mm/page_alloc.c:1540 [inline]
> get_page_from_freelist+0x33ea/0x3570 mm/page_alloc.c:3311
> __alloc_pages+0x255/0x680 mm/page_alloc.c:4567
> __alloc_pages_node include/linux/gfp.h:238 [inline]
> alloc_pages_node include/linux/gfp.h:261 [inline]
> alloc_slab_page+0x5f/0x160 mm/slub.c:2190
> allocate_slab mm/slub.c:2354 [inline]
> new_slab+0x84/0x2f0 mm/slub.c:2407
> ___slab_alloc+0xd17/0x13d0 mm/slub.c:3540
> __slab_alloc mm/slub.c:3625 [inline]
> __slab_alloc_node mm/slub.c:3678 [inline]
> slab_alloc_node mm/slub.c:3850 [inline]
> kmem_cache_alloc+0x249/0x340 mm/slub.c:3867
> vm_area_dup+0x27/0x280 kernel/fork.c:480
> dup_mmap kernel/fork.c:695 [inline]
> dup_mm kernel/fork.c:1685 [inline]
> copy_mm+0xd90/0x21b0 kernel/fork.c:1734
> copy_process+0x1d6f/0x3fb0 kernel/fork.c:2496
> kernel_clone+0x222/0x840 kernel/fork.c:2901
> __do_sys_clone kernel/fork.c:3044 [inline]
> __se_sys_clone kernel/fork.c:3028 [inline]
> __x64_sys_clone+0x258/0x2a0 kernel/fork.c:3028
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
> page last free pid 5037 tgid 5037 stack trace:
> reset_page_owner include/linux/page_owner.h:24 [inline]
> free_pages_prepare mm/page_alloc.c:1140 [inline]
> free_unref_page_prepare+0x959/0xa80 mm/page_alloc.c:2346
> free_unref_page+0x37/0x3f0 mm/page_alloc.c:2486
> pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
> pipe_update_tail fs/pipe.c:234 [inline]
> pipe_read+0x6ee/0x13e0 fs/pipe.c:354
> call_read_iter include/linux/fs.h:2079 [inline]
> new_sync_read fs/read_write.c:395 [inline]
> vfs_read+0x662/0x900 fs/read_write.c:476
> ksys_read+0x1a0/0x2c0 fs/read_write.c:619
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> Memory state around the buggy address:
> ffff88807bb22580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88807bb22600: 00 00 fc fc fc fc fc fc fc fc fc fc fa fb fb fb
>> ffff88807bb22680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88807bb22700: fb fb fb fb fc fc fc fc fc fc fc fc fc fc 00 00
> ffff88807bb22780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> 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.
>
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-03-13 14:32 ` Chao Yu
0 siblings, 0 replies; 21+ messages in thread
From: Chao Yu @ 2024-03-13 14:32 UTC (permalink / raw
To: syzbot, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
#syz test git://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
On 2024/1/15 17:12, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 052d534373b7 Merge tag 'exfat-for-6.8-rc1' of git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14bb9913e80000
> kernel config: https://syzkaller.appspot.com/x/.config?x=490fc2f9d4ae426c
> dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15d9fbcbe80000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1422d5ebe80000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/51de89c7a81e/disk-052d5343.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7e03b92536a3/vmlinux-052d5343.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/3d91124eb5ff/bzImage-052d5343.xz
> mounted in repro #1: https://storage.googleapis.com/syzbot-assets/f67519526788/mount_0.gz
> mounted in repro #2: https://storage.googleapis.com/syzbot-assets/7e871268c842/mount_7.gz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
> Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058
>
> CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
> print_address_description mm/kasan/report.c:377 [inline]
> print_report+0x163/0x540 mm/kasan/report.c:488
> kasan_report+0x142/0x170 mm/kasan/report.c:601
> f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49
> __do_fault+0x131/0x450 mm/memory.c:4376
> do_shared_fault mm/memory.c:4798 [inline]
> do_fault mm/memory.c:4872 [inline]
> do_pte_missing mm/memory.c:3745 [inline]
> handle_pte_fault mm/memory.c:5144 [inline]
> __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285
> handle_mm_fault+0x27e/0x770 mm/memory.c:5450
> do_user_addr_fault arch/x86/mm/fault.c:1364 [inline]
> handle_page_fault arch/x86/mm/fault.c:1507 [inline]
> exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563
> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
> RIP: 0033:0x7f808e742b50
> Code: 20 bf 02 00 00 00 e8 9f 24 04 00 48 83 f8 ff 0f 84 08 fa ff ff 48 89 05 e6 65 0c 00 e9 fc f9 ff ff 66 0f 1f 84 00 00 00 00 00 <c7> 04 25 40 00 00 20 66 32 66 73 c6 04 25 44 00 00 20 00 e9 0f fa
> RSP: 002b:00007f808e735170 EFLAGS: 00010246
>
> RAX: 0000000000000000 RBX: 00007f808e80b6e8 RCX: 00007f808e784fe9
> RDX: 86d0f56bab720225 RSI: 0000000000000000 RDI: 00007f808e7355a0
> RBP: 00007f808e80b6e0 R08: 0000000000000000 R09: 00007f808e7356c0
> R10: 00007f808e80b6e0 R11: 0000000000000246 R12: 00007f808e80b6ec
> R13: 0000000000000000 R14: 00007fff41e6fc30 R15: 00007fff41e6fd18
> </TASK>
>
> Allocated by task 5058:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
> unpoison_slab_object mm/kasan/common.c:314 [inline]
> __kasan_slab_alloc+0x66/0x70 mm/kasan/common.c:340
> kasan_slab_alloc include/linux/kasan.h:201 [inline]
> slab_post_alloc_hook mm/slub.c:3813 [inline]
> slab_alloc_node mm/slub.c:3860 [inline]
> kmem_cache_alloc+0x16f/0x340 mm/slub.c:3867
> vm_area_alloc+0x24/0x1d0 kernel/fork.c:465
> mmap_region+0xbd8/0x1f90 mm/mmap.c:2804
> do_mmap+0x76b/0xde0 mm/mmap.c:1379
> vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
> ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> Freed by task 5064:
> kasan_save_stack mm/kasan/common.c:47 [inline]
> kasan_save_track+0x3f/0x70 mm/kasan/common.c:68
> kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:634
> poison_slab_object+0xa6/0xe0 mm/kasan/common.c:241
> __kasan_slab_free+0x34/0x60 mm/kasan/common.c:257
> kasan_slab_free include/linux/kasan.h:184 [inline]
> slab_free_hook mm/slub.c:2121 [inline]
> slab_free mm/slub.c:4299 [inline]
> kmem_cache_free+0x102/0x2a0 mm/slub.c:4363
> rcu_do_batch kernel/rcu/tree.c:2158 [inline]
> rcu_core+0xad8/0x17c0 kernel/rcu/tree.c:2433
> __do_softirq+0x2b8/0x939 kernel/softirq.c:553
>
> Last potentially related work creation:
> kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
> __kasan_record_aux_stack+0xae/0x100 mm/kasan/generic.c:580
> __call_rcu_common kernel/rcu/tree.c:2683 [inline]
> call_rcu+0x167/0xa80 kernel/rcu/tree.c:2797
> remove_vma mm/mmap.c:148 [inline]
> remove_mt mm/mmap.c:2283 [inline]
> do_vmi_align_munmap+0x159d/0x1930 mm/mmap.c:2629
> do_vmi_munmap+0x24d/0x2d0 mm/mmap.c:2693
> mmap_region+0x677/0x1f90 mm/mmap.c:2744
> do_mmap+0x76b/0xde0 mm/mmap.c:1379
> vm_mmap_pgoff+0x1e2/0x420 mm/util.c:556
> ksys_mmap_pgoff+0x4ff/0x6d0 mm/mmap.c:1425
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> The buggy address belongs to the object at ffff88807bb22660
> which belongs to the cache vm_area_struct of size 192
> The buggy address is located 32 bytes inside of
> freed 192-byte region [ffff88807bb22660, ffff88807bb22720)
>
> The buggy address belongs to the physical page:
> page:ffffea0001eec880 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7bb22
> flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
> page_type: 0xffffffff()
> raw: 00fff00000000800 ffff8880142a1b40 dead000000000122 0000000000000000
> raw: 0000000000000000 00000000800f000f 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 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5039, tgid 5039 (sshd), ts 50202976366, free_ts 44674399535
> set_page_owner include/linux/page_owner.h:31 [inline]
> post_alloc_hook+0x1e6/0x210 mm/page_alloc.c:1533
> prep_new_page mm/page_alloc.c:1540 [inline]
> get_page_from_freelist+0x33ea/0x3570 mm/page_alloc.c:3311
> __alloc_pages+0x255/0x680 mm/page_alloc.c:4567
> __alloc_pages_node include/linux/gfp.h:238 [inline]
> alloc_pages_node include/linux/gfp.h:261 [inline]
> alloc_slab_page+0x5f/0x160 mm/slub.c:2190
> allocate_slab mm/slub.c:2354 [inline]
> new_slab+0x84/0x2f0 mm/slub.c:2407
> ___slab_alloc+0xd17/0x13d0 mm/slub.c:3540
> __slab_alloc mm/slub.c:3625 [inline]
> __slab_alloc_node mm/slub.c:3678 [inline]
> slab_alloc_node mm/slub.c:3850 [inline]
> kmem_cache_alloc+0x249/0x340 mm/slub.c:3867
> vm_area_dup+0x27/0x280 kernel/fork.c:480
> dup_mmap kernel/fork.c:695 [inline]
> dup_mm kernel/fork.c:1685 [inline]
> copy_mm+0xd90/0x21b0 kernel/fork.c:1734
> copy_process+0x1d6f/0x3fb0 kernel/fork.c:2496
> kernel_clone+0x222/0x840 kernel/fork.c:2901
> __do_sys_clone kernel/fork.c:3044 [inline]
> __se_sys_clone kernel/fork.c:3028 [inline]
> __x64_sys_clone+0x258/0x2a0 kernel/fork.c:3028
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
> page last free pid 5037 tgid 5037 stack trace:
> reset_page_owner include/linux/page_owner.h:24 [inline]
> free_pages_prepare mm/page_alloc.c:1140 [inline]
> free_unref_page_prepare+0x959/0xa80 mm/page_alloc.c:2346
> free_unref_page+0x37/0x3f0 mm/page_alloc.c:2486
> pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
> pipe_update_tail fs/pipe.c:234 [inline]
> pipe_read+0x6ee/0x13e0 fs/pipe.c:354
> call_read_iter include/linux/fs.h:2079 [inline]
> new_sync_read fs/read_write.c:395 [inline]
> vfs_read+0x662/0x900 fs/read_write.c:476
> ksys_read+0x1a0/0x2c0 fs/read_write.c:619
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x63/0x6b
>
> Memory state around the buggy address:
> ffff88807bb22580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88807bb22600: 00 00 fc fc fc fc fc fc fc fc fc fc fa fb fb fb
>> ffff88807bb22680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff88807bb22700: fb fb fb fb fc fc fc fc fc fc fc fc fc fc 00 00
> ffff88807bb22780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> 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.
>
> 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
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-03-13 14:32 ` [f2fs-dev] " Chao Yu
@ 2024-03-13 14:50 ` syzbot
-1 siblings, 0 replies; 21+ messages in thread
From: syzbot @ 2024-03-13 14:50 UTC (permalink / raw
To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
Tested on:
commit: 51fc665a f2fs: fix to avoid use-after-free issue in f2..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
console output: https://syzkaller.appspot.com/x/log.txt?x=113bf9fa180000
kernel config: https://syzkaller.appspot.com/x/.config?x=1fcc0a6ff51770e5
dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-03-13 14:50 ` syzbot
0 siblings, 0 replies; 21+ messages in thread
From: syzbot @ 2024-03-13 14:50 UTC (permalink / raw
To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
syzkaller-bugs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: syzbot+763afad57075d3f862f2@syzkaller.appspotmail.com
Tested on:
commit: 51fc665a f2fs: fix to avoid use-after-free issue in f2..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
console output: https://syzkaller.appspot.com/x/log.txt?x=113bf9fa180000
kernel config: https://syzkaller.appspot.com/x/.config?x=1fcc0a6ff51770e5
dashboard link: https://syzkaller.appspot.com/bug?extid=763afad57075d3f862f2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
2024-03-13 1:31 ` [f2fs-dev] " Jaegeuk Kim
@ 2024-03-14 2:19 ` Chao Yu
-1 siblings, 0 replies; 21+ messages in thread
From: Chao Yu @ 2024-03-14 2:19 UTC (permalink / raw
To: Jaegeuk Kim, hdanton@sina.com, Ed Tsai (蔡宗軒)
Cc: Chun-Hung Wu (巫駿宏),
linux-kernel@vger.kernel.org,
Light Hsieh (謝明燈),
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Freddy Hsin (辛恒豐)
On 2024/3/13 9:31, Jaegeuk Kim wrote:
> On 03/12, Ed Tsai (蔡宗軒) wrote:
>> On Mon, 2024-01-15 at 20:05 +0800, Hillf Danton wrote:
>>>
>>> ...
>>>
>>> --- x/fs/f2fs/file.c
>>> +++ y/fs/f2fs/file.c
>>> @@ -39,6 +39,7 @@
>>> static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
>>> {
>>> struct inode *inode = file_inode(vmf->vma->vm_file);
>>> + vm_flags_t flags = vmf->vma->vm_flags;
>>> vm_fault_t ret;
>>>
>>> ret = filemap_fault(vmf);
>>> @@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
>>> f2fs_update_iostat(F2FS_I_SB(inode), inode,
>>> APP_MAPPED_READ_IO,
>>> F2FS_BLKSIZE);
>>>
>>> - trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma-
>>>> vm_flags, ret);
>>> + trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
>>>
>>> return ret;
>>> }
>>> --
>>
>> Hi Jaegeuk,
>>
>> We recently encountered this slabe-use-after-free issue in KASAN as
>> well. Could you please review the patch above and merge it into f2fs?
>
> Where is the patch?
Hi, all,
I'd like to fix this issue in 6.9-rc1, so I submitted a formal patch based on
above code, and the patch has been tested by syzbot.
https://lore.kernel.org/linux-f2fs-devel/20240314020528.3051533-1-chao@kernel.org
Hillf, may I change author of the patch to you? :)
Thanks,
>
>>
>> Best,
>> Ed
>>
>> ==================================================================
>> [29195.369964][T31720] BUG: KASAN: slab-use-after-free in
>> f2fs_filemap_fault+0x50/0xe0
>> [29195.370971][T31720] Read at addr f7ffff80454ebde0 by task AsyncTask
>> #11/31720
>> [29195.371881][T31720] Pointer tag: [f7], memory tag: [f1]
>> [29195.372549][T31720]
>> [29195.372838][T31720] CPU: 2 PID: 31720 Comm: AsyncTask #11 Tainted:
>> G W OE 6.6.17-android15-0-gcb5ba718a525 #1
>> [29195.374862][T31720] Call trace:
>> [29195.375268][T31720] dump_backtrace+0xec/0x138
>> [29195.375848][T31720] show_stack+0x18/0x24
>> [29195.376365][T31720] dump_stack_lvl+0x50/0x6c
>> [29195.376943][T31720] print_report+0x1b0/0x714
>> [29195.377520][T31720] kasan_report+0xc4/0x124
>> [29195.378076][T31720] __do_kernel_fault+0xb8/0x26c
>> [29195.378694][T31720] do_bad_area+0x30/0xdc
>> [29195.379226][T31720] do_tag_check_fault+0x20/0x34
>> [29195.379834][T31720] do_mem_abort+0x58/0x104
>> [29195.380388][T31720] el1_abort+0x3c/0x5c
>> [29195.380899][T31720] el1h_64_sync_handler+0x54/0x90
>> [29195.381529][T31720] el1h_64_sync+0x68/0x6c
>> [29195.382069][T31720] f2fs_filemap_fault+0x50/0xe0
>> [29195.382678][T31720] __do_fault+0xc8/0xfc
>> [29195.383209][T31720] handle_mm_fault+0xb44/0x10c4
>> [29195.383816][T31720] do_page_fault+0x294/0x48c
>> [29195.384395][T31720] do_translation_fault+0x38/0x54
>> [29195.385023][T31720] do_mem_abort+0x58/0x104
>> [29195.385577][T31720] el0_da+0x44/0x78
>> [29195.386057][T31720] el0t_64_sync_handler+0x98/0xbc
>> [29195.386688][T31720] el0t_64_sync+0x1a8/0x1ac
>> [29195.387249][T31720]
>> [29195.387534][T31720] Allocated by task 14784:
>> [29195.388085][T31720] kasan_save_stack+0x40/0x70
>> [29195.388672][T31720] save_stack_info+0x34/0x128
>> [29195.389259][T31720] kasan_save_alloc_info+0x14/0x20
>> [29195.389901][T31720] __kasan_slab_alloc+0x168/0x174
>> [29195.390530][T31720] slab_post_alloc_hook+0x88/0x3a4
>> [29195.391168][T31720] kmem_cache_alloc+0x18c/0x2c8
>> [29195.391771][T31720] vm_area_alloc+0x2c/0xe8
>> [29195.392327][T31720] mmap_region+0x440/0xa94
>> [29195.392888][T31720] do_mmap+0x3d0/0x524
>> [29195.393399][T31720] vm_mmap_pgoff+0x1a0/0x1f8
>> [29195.393980][T31720] ksys_mmap_pgoff+0x78/0xf4
>> [29195.394557][T31720] __arm64_sys_mmap+0x34/0x44
>> [29195.395138][T31720] invoke_syscall+0x58/0x114
>> [29195.395727][T31720] el0_svc_common+0x80/0xe0
>> [29195.396292][T31720] do_el0_svc+0x1c/0x28
>> [29195.396812][T31720] el0_svc+0x38/0x68
>> [29195.397302][T31720] el0t_64_sync_handler+0x68/0xbc
>> [29195.397932][T31720] el0t_64_sync+0x1a8/0x1ac
>> [29195.398492][T31720]
>> [29195.398778][T31720] Freed by task 0:
>> [29195.399240][T31720] kasan_save_stack+0x40/0x70
>> [29195.399825][T31720] save_stack_info+0x34/0x128
>> [29195.400412][T31720] kasan_save_free_info+0x18/0x28
>> [29195.401043][T31720] ____kasan_slab_free+0x254/0x25c
>> [29195.401682][T31720] __kasan_slab_free+0x10/0x20
>> [29195.402278][T31720] slab_free_freelist_hook+0x174/0x1e0
>> [29195.402961][T31720] kmem_cache_free+0xc4/0x348
>> [29195.403544][T31720] __vm_area_free+0x84/0xa4
>> [29195.404103][T31720] vm_area_free_rcu_cb+0x10/0x20
>> [29195.404719][T31720] rcu_do_batch+0x214/0x720
>> [29195.405284][T31720] rcu_core+0x1b0/0x408
>> [29195.405800][T31720] rcu_core_si+0x10/0x20
>> [29195.406348][T31720] __do_softirq+0x120/0x3f4
>> [29195.406907][T31720]
>> [29195.407191][T31720] The buggy address belongs to the object at
>> ffffff80454ebdc0
>> [29195.407191][T31720] which belongs to the cache vm_area_struct of
>> size 176
>> [29195.408978][T31720] The buggy address is located 32 bytes inside of
>> [29195.408978][T31720] 176-byte region [ffffff80454ebdc0,
>> ffffff80454ebe70)
>> [29195.410625][T31720]
>> [29195.410911][T31720] The buggy address belongs to the physical page:
>> [29195.411709][T31720] page:0000000058f0f2f1 refcount:1 mapcount:0
>> mapping:0000000000000000 index:0x0 pfn:0xc54eb
>> [29195.412980][T31720] anon flags:
>> 0x4000000000000800(slab|zone=1|kasantag=0x0)
>> [29195.413880][T31720] page_type: 0xffffffff()
>> [29195.414418][T31720] raw: 4000000000000800 f6ffff8002904500
>> fffffffe076fc8c0 dead000000000007
>> [29195.415488][T31720] raw: 0000000000000000 0000000000170017
>> 00000001ffffffff 0000000000000000
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-03-14 2:19 ` Chao Yu
0 siblings, 0 replies; 21+ messages in thread
From: Chao Yu @ 2024-03-14 2:19 UTC (permalink / raw
To: Jaegeuk Kim, hdanton@sina.com, Ed Tsai (蔡宗軒)
Cc: Chun-Hung Wu (巫駿宏),
linux-kernel@vger.kernel.org,
Light Hsieh (謝明燈),
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Freddy Hsin (辛恒豐)
On 2024/3/13 9:31, Jaegeuk Kim wrote:
> On 03/12, Ed Tsai (蔡宗軒) wrote:
>> On Mon, 2024-01-15 at 20:05 +0800, Hillf Danton wrote:
>>>
>>> ...
>>>
>>> --- x/fs/f2fs/file.c
>>> +++ y/fs/f2fs/file.c
>>> @@ -39,6 +39,7 @@
>>> static vm_fault_t f2fs_filemap_fault(struct vm_fault *vmf)
>>> {
>>> struct inode *inode = file_inode(vmf->vma->vm_file);
>>> + vm_flags_t flags = vmf->vma->vm_flags;
>>> vm_fault_t ret;
>>>
>>> ret = filemap_fault(vmf);
>>> @@ -46,7 +47,7 @@ static vm_fault_t f2fs_filemap_fault(str
>>> f2fs_update_iostat(F2FS_I_SB(inode), inode,
>>> APP_MAPPED_READ_IO,
>>> F2FS_BLKSIZE);
>>>
>>> - trace_f2fs_filemap_fault(inode, vmf->pgoff, vmf->vma-
>>>> vm_flags, ret);
>>> + trace_f2fs_filemap_fault(inode, vmf->pgoff, flags, ret);
>>>
>>> return ret;
>>> }
>>> --
>>
>> Hi Jaegeuk,
>>
>> We recently encountered this slabe-use-after-free issue in KASAN as
>> well. Could you please review the patch above and merge it into f2fs?
>
> Where is the patch?
Hi, all,
I'd like to fix this issue in 6.9-rc1, so I submitted a formal patch based on
above code, and the patch has been tested by syzbot.
https://lore.kernel.org/linux-f2fs-devel/20240314020528.3051533-1-chao@kernel.org
Hillf, may I change author of the patch to you? :)
Thanks,
>
>>
>> Best,
>> Ed
>>
>> ==================================================================
>> [29195.369964][T31720] BUG: KASAN: slab-use-after-free in
>> f2fs_filemap_fault+0x50/0xe0
>> [29195.370971][T31720] Read at addr f7ffff80454ebde0 by task AsyncTask
>> #11/31720
>> [29195.371881][T31720] Pointer tag: [f7], memory tag: [f1]
>> [29195.372549][T31720]
>> [29195.372838][T31720] CPU: 2 PID: 31720 Comm: AsyncTask #11 Tainted:
>> G W OE 6.6.17-android15-0-gcb5ba718a525 #1
>> [29195.374862][T31720] Call trace:
>> [29195.375268][T31720] dump_backtrace+0xec/0x138
>> [29195.375848][T31720] show_stack+0x18/0x24
>> [29195.376365][T31720] dump_stack_lvl+0x50/0x6c
>> [29195.376943][T31720] print_report+0x1b0/0x714
>> [29195.377520][T31720] kasan_report+0xc4/0x124
>> [29195.378076][T31720] __do_kernel_fault+0xb8/0x26c
>> [29195.378694][T31720] do_bad_area+0x30/0xdc
>> [29195.379226][T31720] do_tag_check_fault+0x20/0x34
>> [29195.379834][T31720] do_mem_abort+0x58/0x104
>> [29195.380388][T31720] el1_abort+0x3c/0x5c
>> [29195.380899][T31720] el1h_64_sync_handler+0x54/0x90
>> [29195.381529][T31720] el1h_64_sync+0x68/0x6c
>> [29195.382069][T31720] f2fs_filemap_fault+0x50/0xe0
>> [29195.382678][T31720] __do_fault+0xc8/0xfc
>> [29195.383209][T31720] handle_mm_fault+0xb44/0x10c4
>> [29195.383816][T31720] do_page_fault+0x294/0x48c
>> [29195.384395][T31720] do_translation_fault+0x38/0x54
>> [29195.385023][T31720] do_mem_abort+0x58/0x104
>> [29195.385577][T31720] el0_da+0x44/0x78
>> [29195.386057][T31720] el0t_64_sync_handler+0x98/0xbc
>> [29195.386688][T31720] el0t_64_sync+0x1a8/0x1ac
>> [29195.387249][T31720]
>> [29195.387534][T31720] Allocated by task 14784:
>> [29195.388085][T31720] kasan_save_stack+0x40/0x70
>> [29195.388672][T31720] save_stack_info+0x34/0x128
>> [29195.389259][T31720] kasan_save_alloc_info+0x14/0x20
>> [29195.389901][T31720] __kasan_slab_alloc+0x168/0x174
>> [29195.390530][T31720] slab_post_alloc_hook+0x88/0x3a4
>> [29195.391168][T31720] kmem_cache_alloc+0x18c/0x2c8
>> [29195.391771][T31720] vm_area_alloc+0x2c/0xe8
>> [29195.392327][T31720] mmap_region+0x440/0xa94
>> [29195.392888][T31720] do_mmap+0x3d0/0x524
>> [29195.393399][T31720] vm_mmap_pgoff+0x1a0/0x1f8
>> [29195.393980][T31720] ksys_mmap_pgoff+0x78/0xf4
>> [29195.394557][T31720] __arm64_sys_mmap+0x34/0x44
>> [29195.395138][T31720] invoke_syscall+0x58/0x114
>> [29195.395727][T31720] el0_svc_common+0x80/0xe0
>> [29195.396292][T31720] do_el0_svc+0x1c/0x28
>> [29195.396812][T31720] el0_svc+0x38/0x68
>> [29195.397302][T31720] el0t_64_sync_handler+0x68/0xbc
>> [29195.397932][T31720] el0t_64_sync+0x1a8/0x1ac
>> [29195.398492][T31720]
>> [29195.398778][T31720] Freed by task 0:
>> [29195.399240][T31720] kasan_save_stack+0x40/0x70
>> [29195.399825][T31720] save_stack_info+0x34/0x128
>> [29195.400412][T31720] kasan_save_free_info+0x18/0x28
>> [29195.401043][T31720] ____kasan_slab_free+0x254/0x25c
>> [29195.401682][T31720] __kasan_slab_free+0x10/0x20
>> [29195.402278][T31720] slab_free_freelist_hook+0x174/0x1e0
>> [29195.402961][T31720] kmem_cache_free+0xc4/0x348
>> [29195.403544][T31720] __vm_area_free+0x84/0xa4
>> [29195.404103][T31720] vm_area_free_rcu_cb+0x10/0x20
>> [29195.404719][T31720] rcu_do_batch+0x214/0x720
>> [29195.405284][T31720] rcu_core+0x1b0/0x408
>> [29195.405800][T31720] rcu_core_si+0x10/0x20
>> [29195.406348][T31720] __do_softirq+0x120/0x3f4
>> [29195.406907][T31720]
>> [29195.407191][T31720] The buggy address belongs to the object at
>> ffffff80454ebdc0
>> [29195.407191][T31720] which belongs to the cache vm_area_struct of
>> size 176
>> [29195.408978][T31720] The buggy address is located 32 bytes inside of
>> [29195.408978][T31720] 176-byte region [ffffff80454ebdc0,
>> ffffff80454ebe70)
>> [29195.410625][T31720]
>> [29195.410911][T31720] The buggy address belongs to the physical page:
>> [29195.411709][T31720] page:0000000058f0f2f1 refcount:1 mapcount:0
>> mapping:0000000000000000 index:0x0 pfn:0xc54eb
>> [29195.412980][T31720] anon flags:
>> 0x4000000000000800(slab|zone=1|kasantag=0x0)
>> [29195.413880][T31720] page_type: 0xffffffff()
>> [29195.414418][T31720] raw: 4000000000000800 f6ffff8002904500
>> fffffffe076fc8c0 dead000000000007
>> [29195.415488][T31720] raw: 0000000000000000 0000000000170017
>> 00000001ffffffff 0000000000000000
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* f2fs F2FS_IOC_SHUTDOWN hang issue
[not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>
@ 2024-03-20 6:59 ` Light Hsieh (謝明燈)
2024-03-20 20:06 ` [f2fs-dev] " Jaegeuk Kim
1 sibling, 0 replies; 21+ messages in thread
From: Light Hsieh (謝明燈) @ 2024-03-20 6:59 UTC (permalink / raw
To: Ed Tsai (蔡宗軒), jaegeuk@kernel.org
Cc: linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
Hi Jaegeuk:
We encounter a deadlock issue when Android is going to poweroff.
Please help check.
When unmounting of f2fs partition fail in Android poweroff procedure, init thread (pid = 1) invoke F2FS_IOC_SHUTDOWN ioctl with arg F2FS_GOING_DOWN_FULLSYNC.
This ioctl cause down_write of a semaphore in the following call sequence:
f2fs_ioc_shutdown() --> freeze_bdev() --> freeze_super() --> sb_wait_write(sb, SB_FREEZE_FS) --> ... ->percpu_down_write().
f2fs_ioc_shutdown() will later invoke f2fs_stop_discard_thread() and wait for stopping of f2fs_discard thread in the following call sequence:
f2fs_ioc_shutdown() -->f2fs_stop_discard_thread() -->kthread_stop(discard_thread) --> wait_for_completion().
That is, init thread go sleep with a write semaphore.
f2fs_discard thread is then waken up to process f2fs discard.
However, f2fs_discard threshold may then hang because failing to get the semaphore aleady obtained by the slept init thread:
issue_discard_thread() --> sb_start_intwrite() -->sb_start_write(sb, SB_FREEZE_FS) --> percpu_down_read()
Light
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: f2fs F2FS_IOC_SHUTDOWN hang issue
[not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>
@ 2024-03-20 20:06 ` Jaegeuk Kim
2024-03-20 20:06 ` [f2fs-dev] " Jaegeuk Kim
1 sibling, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-20 20:06 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: Ed Tsai (蔡宗軒), linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
Can you try this?
https://patchwork.kernel.org/project/f2fs/patch/20240320001442.497813-1-jaegeuk@kernel.org/
On 03/20, Light Hsieh (謝明燈) wrote:
> Hi Jaegeuk:
>
> We encounter a deadlock issue when Android is going to poweroff.
> Please help check.
>
> When unmounting of f2fs partition fail in Android poweroff procedure, init thread (pid = 1) invoke F2FS_IOC_SHUTDOWN ioctl with arg F2FS_GOING_DOWN_FULLSYNC.
> This ioctl cause down_write of a semaphore in the following call sequence:
> f2fs_ioc_shutdown() --> freeze_bdev() --> freeze_super() --> sb_wait_write(sb, SB_FREEZE_FS) --> ... ->percpu_down_write().
>
> f2fs_ioc_shutdown() will later invoke f2fs_stop_discard_thread() and wait for stopping of f2fs_discard thread in the following call sequence:
> f2fs_ioc_shutdown() -->f2fs_stop_discard_thread() -->kthread_stop(discard_thread) --> wait_for_completion().
> That is, init thread go sleep with a write semaphore.
>
> f2fs_discard thread is then waken up to process f2fs discard.
> However, f2fs_discard threshold may then hang because failing to get the semaphore aleady obtained by the slept init thread:
> issue_discard_thread() --> sb_start_intwrite() -->sb_start_write(sb, SB_FREEZE_FS) --> percpu_down_read()
>
> Light
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] f2fs F2FS_IOC_SHUTDOWN hang issue
@ 2024-03-20 20:06 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-20 20:06 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏),
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Ed Tsai (蔡宗軒)
Can you try this?
https://patchwork.kernel.org/project/f2fs/patch/20240320001442.497813-1-jaegeuk@kernel.org/
On 03/20, Light Hsieh (謝明燈) wrote:
> Hi Jaegeuk:
>
> We encounter a deadlock issue when Android is going to poweroff.
> Please help check.
>
> When unmounting of f2fs partition fail in Android poweroff procedure, init thread (pid = 1) invoke F2FS_IOC_SHUTDOWN ioctl with arg F2FS_GOING_DOWN_FULLSYNC.
> This ioctl cause down_write of a semaphore in the following call sequence:
> f2fs_ioc_shutdown() --> freeze_bdev() --> freeze_super() --> sb_wait_write(sb, SB_FREEZE_FS) --> ... ->percpu_down_write().
>
> f2fs_ioc_shutdown() will later invoke f2fs_stop_discard_thread() and wait for stopping of f2fs_discard thread in the following call sequence:
> f2fs_ioc_shutdown() -->f2fs_stop_discard_thread() -->kthread_stop(discard_thread) --> wait_for_completion().
> That is, init thread go sleep with a write semaphore.
>
> f2fs_discard thread is then waken up to process f2fs discard.
> However, f2fs_discard threshold may then hang because failing to get the semaphore aleady obtained by the slept init thread:
> issue_discard_thread() --> sb_start_intwrite() -->sb_start_write(sb, SB_FREEZE_FS) --> percpu_down_read()
>
> Light
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
2024-03-20 20:06 ` [f2fs-dev] " Jaegeuk Kim
(?)
@ 2024-03-20 23:34 ` Light Hsieh (謝明燈)
2024-03-21 0:39 ` [f2fs-dev] " Jaegeuk Kim
-1 siblings, 1 reply; 21+ messages in thread
From: Light Hsieh (謝明燈) @ 2024-03-20 23:34 UTC (permalink / raw
To: Jaegeuk Kim
Cc: Ed Tsai (蔡宗軒), linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
On 2024/3/20 8:14, Jaegeuk Kim wrote:
> f2fs_ioc_shutdown(F2FS_GOING_DOWN_NOSYNC) issue_discard_thread
> - mnt_want_write_file()
> - sb_start_write(SB_FREEZE_WRITE)
> - sb_start_intwrite(SB_FREEZE_FS);
> - f2fs_stop_checkpoint(sbi, false, : waiting
> STOP_CP_REASON_SHUTDOWN);
> - f2fs_stop_discard_thread(sbi);
> - kthread_stop()
> : waiting
>
> - mnt_drop_write_file(filp);
>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
The case I encounter is f2fs_ic_shutdown with arg F2FS_GOING_DOWN_FULLSYNC, not F2FS_GOING_DOWN_NOSYNC.
Or you are meaning that: besides the kernel patch, I need to change the invoked F2FS_IOC_SHUTDOWN to use arg F2FS_GOING_DOWN_NOSYNC?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
2024-03-20 23:34 ` 回覆: " Light Hsieh (謝明燈)
@ 2024-03-21 0:39 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-21 0:39 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: Ed Tsai (蔡宗軒), linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
On 03/20, Light Hsieh (謝明燈) wrote:
> On 2024/3/20 8:14, Jaegeuk Kim wrote:
> > f2fs_ioc_shutdown(F2FS_GOING_DOWN_NOSYNC) issue_discard_thread
> > - mnt_want_write_file()
> > - sb_start_write(SB_FREEZE_WRITE)
> > - sb_start_intwrite(SB_FREEZE_FS);
> > - f2fs_stop_checkpoint(sbi, false, : waiting
> > STOP_CP_REASON_SHUTDOWN);
> > - f2fs_stop_discard_thread(sbi);
> > - kthread_stop()
> > : waiting
> >
> > - mnt_drop_write_file(filp);
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> The case I encounter is f2fs_ic_shutdown with arg F2FS_GOING_DOWN_FULLSYNC, not F2FS_GOING_DOWN_NOSYNC.
>
> Or you are meaning that: besides the kernel patch, I need to change the invoked F2FS_IOC_SHUTDOWN to use arg F2FS_GOING_DOWN_NOSYNC?
I think this patch also addresses your case by using trylock.
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
@ 2024-03-21 0:39 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-21 0:39 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏),
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Ed Tsai (蔡宗軒)
On 03/20, Light Hsieh (謝明燈) wrote:
> On 2024/3/20 8:14, Jaegeuk Kim wrote:
> > f2fs_ioc_shutdown(F2FS_GOING_DOWN_NOSYNC) issue_discard_thread
> > - mnt_want_write_file()
> > - sb_start_write(SB_FREEZE_WRITE)
> > - sb_start_intwrite(SB_FREEZE_FS);
> > - f2fs_stop_checkpoint(sbi, false, : waiting
> > STOP_CP_REASON_SHUTDOWN);
> > - f2fs_stop_discard_thread(sbi);
> > - kthread_stop()
> > : waiting
> >
> > - mnt_drop_write_file(filp);
> >
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>
> The case I encounter is f2fs_ic_shutdown with arg F2FS_GOING_DOWN_FULLSYNC, not F2FS_GOING_DOWN_NOSYNC.
>
> Or you are meaning that: besides the kernel patch, I need to change the invoked F2FS_IOC_SHUTDOWN to use arg F2FS_GOING_DOWN_NOSYNC?
I think this patch also addresses your case by using trylock.
>
>
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 回覆: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
[not found] ` <SI2PR03MB52605816252C9ABA3D8550F084322@SI2PR03MB5260.apcprd03.prod.outlook.com>
@ 2024-03-22 0:30 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-22 0:30 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: Ed Tsai (蔡宗軒), linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏)
On 03/21, Light Hsieh (謝明燈) wrote:
> Do you mean:
>
> + /* Avoid the deadlock from F2FS_GOING_DOWN_NOSYNC. */
> + if (!sb_start_intwrite_trylock(sbi->sb))
> + continue;
>
> After failure of trylock, the 'continue' make code flow goto the line:
> } while (!kthread_should_stop());
> Since kthrad_should_stop() is true now, so the issue_discard_thread will end?
Yes, but now I'm confused who is taking write_sem. :(
>
> Light
> ________________________________
> 寄件者: Jaegeuk Kim <jaegeuk@kernel.org>
> 寄件日期: 2024年3月21日 上午 08:39
> 收件者: Light Hsieh (謝明燈) <Light.Hsieh@mediatek.com>
> 副本: Ed Tsai (蔡宗軒) <Ed.Tsai@mediatek.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-f2fs-devel@lists.sourceforge.net <linux-f2fs-devel@lists.sourceforge.net>; linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>; Chun-Hung Wu (巫駿宏) <Chun-hung.Wu@mediatek.com>
> 主旨: Re: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
>
>
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> On 03/20, Light Hsieh (謝明燈) wrote:
> > On 2024/3/20 8:14, Jaegeuk Kim wrote:
> > > f2fs_ioc_shutdown(F2FS_GOING_DOWN_NOSYNC) issue_discard_thread
> > > - mnt_want_write_file()
> > > - sb_start_write(SB_FREEZE_WRITE)
> > > - sb_start_intwrite(SB_FREEZE_FS);
> > > - f2fs_stop_checkpoint(sbi, false, : waiting
> > > STOP_CP_REASON_SHUTDOWN);
> > > - f2fs_stop_discard_thread(sbi);
> > > - kthread_stop()
> > > : waiting
> > >
> > > - mnt_drop_write_file(filp);
> > >
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> >
> > The case I encounter is f2fs_ic_shutdown with arg F2FS_GOING_DOWN_FULLSYNC, not F2FS_GOING_DOWN_NOSYNC.
> >
> > Or you are meaning that: besides the kernel patch, I need to change the invoked F2FS_IOC_SHUTDOWN to use arg F2FS_GOING_DOWN_NOSYNC?
>
> I think this patch also addresses your case by using trylock.
>
> >
> >
> >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [f2fs-dev] 回覆: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
@ 2024-03-22 0:30 ` Jaegeuk Kim
0 siblings, 0 replies; 21+ messages in thread
From: Jaegeuk Kim @ 2024-03-22 0:30 UTC (permalink / raw
To: Light Hsieh (謝明燈)
Cc: linux-fsdevel@vger.kernel.org,
Chun-Hung Wu (巫駿宏),
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Ed Tsai (蔡宗軒)
On 03/21, Light Hsieh (謝明燈) wrote:
> Do you mean:
>
> + /* Avoid the deadlock from F2FS_GOING_DOWN_NOSYNC. */
> + if (!sb_start_intwrite_trylock(sbi->sb))
> + continue;
>
> After failure of trylock, the 'continue' make code flow goto the line:
> } while (!kthread_should_stop());
> Since kthrad_should_stop() is true now, so the issue_discard_thread will end?
Yes, but now I'm confused who is taking write_sem. :(
>
> Light
> ________________________________
> 寄件者: Jaegeuk Kim <jaegeuk@kernel.org>
> 寄件日期: 2024年3月21日 上午 08:39
> 收件者: Light Hsieh (謝明燈) <Light.Hsieh@mediatek.com>
> 副本: Ed Tsai (蔡宗軒) <Ed.Tsai@mediatek.com>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-f2fs-devel@lists.sourceforge.net <linux-f2fs-devel@lists.sourceforge.net>; linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>; Chun-Hung Wu (巫駿宏) <Chun-hung.Wu@mediatek.com>
> 主旨: Re: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue
>
>
> External email : Please do not click links or open attachments until you have verified the sender or the content.
>
>
> On 03/20, Light Hsieh (謝明燈) wrote:
> > On 2024/3/20 8:14, Jaegeuk Kim wrote:
> > > f2fs_ioc_shutdown(F2FS_GOING_DOWN_NOSYNC) issue_discard_thread
> > > - mnt_want_write_file()
> > > - sb_start_write(SB_FREEZE_WRITE)
> > > - sb_start_intwrite(SB_FREEZE_FS);
> > > - f2fs_stop_checkpoint(sbi, false, : waiting
> > > STOP_CP_REASON_SHUTDOWN);
> > > - f2fs_stop_discard_thread(sbi);
> > > - kthread_stop()
> > > : waiting
> > >
> > > - mnt_drop_write_file(filp);
> > >
> > > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> >
> > The case I encounter is f2fs_ic_shutdown with arg F2FS_GOING_DOWN_FULLSYNC, not F2FS_GOING_DOWN_NOSYNC.
> >
> > Or you are meaning that: besides the kernel patch, I need to change the invoked F2FS_IOC_SHUTDOWN to use arg F2FS_GOING_DOWN_NOSYNC?
>
> I think this patch also addresses your case by using trylock.
>
> >
> >
> >
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2024-03-22 0:30 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-15 9:12 [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault syzbot
2024-01-15 9:12 ` [f2fs-dev] " syzbot
2024-01-15 12:05 ` Hillf Danton
2024-01-15 19:17 ` syzbot
2024-03-12 1:33 ` Ed Tsai (蔡宗軒)
2024-03-13 1:31 ` Jaegeuk Kim
2024-03-13 1:31 ` [f2fs-dev] " Jaegeuk Kim
2024-03-14 2:19 ` Chao Yu
2024-03-14 2:19 ` Chao Yu
[not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>
2024-03-20 6:59 ` f2fs F2FS_IOC_SHUTDOWN hang issue Light Hsieh (謝明燈)
2024-03-20 20:06 ` Jaegeuk Kim
2024-03-20 20:06 ` [f2fs-dev] " Jaegeuk Kim
2024-03-20 23:34 ` 回覆: " Light Hsieh (謝明燈)
2024-03-21 0:39 ` Jaegeuk Kim
2024-03-21 0:39 ` [f2fs-dev] " Jaegeuk Kim
[not found] ` <SI2PR03MB52605816252C9ABA3D8550F084322@SI2PR03MB5260.apcprd03.prod.outlook.com>
2024-03-22 0:30 ` 回覆: " Jaegeuk Kim
2024-03-22 0:30 ` [f2fs-dev] " Jaegeuk Kim
2024-03-13 14:32 ` [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault Chao Yu
2024-03-13 14:32 ` [f2fs-dev] " Chao Yu
2024-03-13 14:50 ` syzbot
2024-03-13 14:50 ` [f2fs-dev] " syzbot
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.