* [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault
@ 2024-01-15 9:12 syzbot
2024-01-15 12:05 ` Hillf Danton
2024-03-13 14:32 ` [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault Chao Yu
0 siblings, 2 replies; 13+ 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] 13+ messages in thread* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault 2024-01-15 9:12 [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault syzbot @ 2024-01-15 12:05 ` Hillf Danton 2024-01-15 19:17 ` syzbot 2024-03-12 1:33 ` Ed Tsai (蔡宗軒) 2024-03-13 14:32 ` [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault Chao Yu 1 sibling, 2 replies; 13+ 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] 13+ 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; 13+ 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] 13+ 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 ` Jaegeuk Kim [not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com> 1 sibling, 2 replies; 13+ messages in thread From: Ed Tsai (蔡宗軒) @ 2024-03-12 1:33 UTC (permalink / raw) To: jaegeuk, hdanton Cc: Light Hsieh (謝明燈), linux-kernel, linux-f2fs-devel, Freddy Hsin (辛恒豐), linux-fsdevel, 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] 13+ 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 2024-03-14 2:19 ` [f2fs-dev] " Chao Yu [not found] ` <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com> 1 sibling, 1 reply; 13+ messages in thread From: Jaegeuk Kim @ 2024-03-13 1:31 UTC (permalink / raw) To: Ed Tsai (蔡宗軒) Cc: hdanton, Light Hsieh (謝明燈), linux-kernel, linux-f2fs-devel, Freddy Hsin (辛恒豐), linux-fsdevel, 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] 13+ 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 @ 2024-03-14 2:19 ` Chao Yu 0 siblings, 0 replies; 13+ messages in thread From: Chao Yu @ 2024-03-14 2:19 UTC (permalink / raw) To: Jaegeuk Kim, hdanton, Ed Tsai (蔡宗軒) Cc: Chun-Hung Wu (巫駿宏), linux-kernel, Light Hsieh (謝明燈), linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
[parent not found: <SI2PR03MB52600BD4AFAD1E324FD0430584332@SI2PR03MB5260.apcprd03.prod.outlook.com>]
* 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 ` Jaegeuk Kim 1 sibling, 0 replies; 13+ messages in thread From: Light Hsieh (謝明燈) @ 2024-03-20 6:59 UTC (permalink / raw) To: Ed Tsai (蔡宗軒), jaegeuk Cc: linux-kernel, linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
* Re: f2fs F2FS_IOC_SHUTDOWN hang issue [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 23:34 ` 回覆: " Light Hsieh (謝明燈) 1 sibling, 1 reply; 13+ messages in thread From: Jaegeuk Kim @ 2024-03-20 20:06 UTC (permalink / raw) To: Light Hsieh (謝明燈) Cc: Ed Tsai (蔡宗軒), linux-kernel, linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
* 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue 2024-03-20 20:06 ` Jaegeuk Kim @ 2024-03-20 23:34 ` Light Hsieh (謝明燈) 2024-03-21 0:39 ` Jaegeuk Kim 0 siblings, 1 reply; 13+ messages in thread From: Light Hsieh (謝明燈) @ 2024-03-20 23:34 UTC (permalink / raw) To: Jaegeuk Kim Cc: Ed Tsai (蔡宗軒), linux-kernel, linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
* Re: 回覆: f2fs F2FS_IOC_SHUTDOWN hang issue 2024-03-20 23:34 ` 回覆: " Light Hsieh (謝明燈) @ 2024-03-21 0:39 ` Jaegeuk Kim [not found] ` <SI2PR03MB52605816252C9ABA3D8550F084322@SI2PR03MB5260.apcprd03.prod.outlook.com> 0 siblings, 1 reply; 13+ messages in thread From: Jaegeuk Kim @ 2024-03-21 0:39 UTC (permalink / raw) To: Light Hsieh (謝明燈) Cc: Ed Tsai (蔡宗軒), linux-kernel, linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
[parent not found: <SI2PR03MB52605816252C9ABA3D8550F084322@SI2PR03MB5260.apcprd03.prod.outlook.com>]
* 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; 13+ messages in thread From: Jaegeuk Kim @ 2024-03-22 0:30 UTC (permalink / raw) To: Light Hsieh (謝明燈) Cc: Ed Tsai (蔡宗軒), linux-kernel, linux-f2fs-devel, linux-fsdevel, 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] 13+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault 2024-01-15 9:12 [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault syzbot 2024-01-15 12:05 ` Hillf Danton @ 2024-03-13 14:32 ` Chao Yu 2024-03-13 14:50 ` syzbot 1 sibling, 1 reply; 13+ 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] 13+ messages in thread
* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault 2024-03-13 14:32 ` [syzbot] [f2fs?] KASAN: slab-use-after-free Read in f2fs_filemap_fault Chao Yu @ 2024-03-13 14:50 ` syzbot 0 siblings, 0 replies; 13+ 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] 13+ messages in thread
end of thread, other threads:[~2024-03-22 0:30 UTC | newest]
Thread overview: 13+ 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 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-14 2:19 ` [f2fs-dev] " 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 23:34 ` 回覆: " Light Hsieh (謝明燈)
2024-03-21 0:39 ` Jaegeuk Kim
[not found] ` <SI2PR03MB52605816252C9ABA3D8550F084322@SI2PR03MB5260.apcprd03.prod.outlook.com>
2024-03-22 0:30 ` 回覆: " 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:50 ` syzbot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
Powered by JetHome