Hello,
syzbot found the following issue on:
HEAD commit: 11cb68ad52ac Add linux-next specific files for 20240408
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13a6f483180000
kernel config: https://syzkaller.appspot.com/x/.config?x=727d5608101b5d77
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4e90f2d3b1ef/disk-11cb68ad.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d886b454e2cc/vmlinux-11cb68ad.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ed94857c6f92/bzImage-11cb68ad.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
==================================================================
BUG: KASAN: slab-use-after-free in is_vm_hugetlb_page include/linux/hugetlb_inline.h:11 [inline]
BUG: KASAN: slab-use-after-free in vma_resv_map mm/hugetlb.c:1150 [inline]
BUG: KASAN: slab-use-after-free in __vma_reservation_common+0xc9/0x7d0 mm/hugetlb.c:2807
Read of size 8 at addr ffff88807c6434f8 by task syz-executor.2/8726
CPU: 0 PID: 8726 Comm: syz-executor.2 Not tainted 6.9.0-rc3-next-20240408-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
is_vm_hugetlb_page include/linux/hugetlb_inline.h:11 [inline]
vma_resv_map mm/hugetlb.c:1150 [inline]
__vma_reservation_common+0xc9/0x7d0 mm/hugetlb.c:2807
vma_needs_reservation mm/hugetlb.c:2881 [inline]
restore_reserve_on_error+0x39/0x1d0 mm/hugetlb.c:2931
hugetlb_no_page mm/hugetlb.c:6390 [inline]
hugetlb_fault+0x19ae/0x3710 mm/hugetlb.c:6486
handle_mm_fault+0x18e8/0x1bb0 mm/memory.c:5662
do_user_addr_fault arch/x86/mm/fault.c:1368 [inline]
handle_page_fault arch/x86/mm/fault.c:1511 [inline]
exc_page_fault+0x459/0x900 arch/x86/mm/fault.c:1569
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0033:0x7f9770c2c621
Code: 48 8b 54 24 08 48 85 d2 74 17 8b 44 24 18 0f c8 89 c0 48 89 44 24 18 48 83 fa 01 0f 85 b3 01 00 00 48 8b 44 24 10 8b 54 24 18 <89> 10 e9 15 fd ff ff 48 8b 44 24 10 8b 10 48 8b 44 24 08 48 85 c0
RSP: 002b:00007fff24941e70 EFLAGS: 00010246
RAX: 0000000020000000 RBX: 0000000000000004 RCX: 0000000000000000
RDX: 0000000000000194 RSI: 0000000000000000 RDI: 000055558dd3e360
RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
R10: 00007fff24941fe0 R11: 0000000000000246 R12: 00007f9770801138
R13: fffffffffffffffe R14: 00007f9770800000 R15: 00007f9770801140
</TASK>
Allocated by task 8728:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3897 [inline]
slab_alloc_node mm/slub.c:3957 [inline]
kmem_cache_alloc_noprof+0x135/0x290 mm/slub.c:3964
vm_area_alloc+0x24/0x1d0 kernel/fork.c:467
mmap_region+0xc09/0x2020 mm/mmap.c:2852
do_mmap+0x8ad/0xf70 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x53c/0x6e0 mm/mmap.c:1433
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
Freed by task 15:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2190 [inline]
slab_free mm/slub.c:4393 [inline]
kmem_cache_free+0x145/0x340 mm/slub.c:4468
rcu_do_batch kernel/rcu/tree.c:2215 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2489
__do_softirq+0x2c6/0x980 kernel/softirq.c:554
Last potentially related work creation:
kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
__kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
__call_rcu_common kernel/rcu/tree.c:2752 [inline]
call_rcu+0x167/0xa70 kernel/rcu/tree.c:2856
remove_vma mm/mmap.c:148 [inline]
remove_mt mm/mmap.c:2334 [inline]
do_vmi_align_munmap+0x155c/0x18c0 mm/mmap.c:2677
do_vmi_munmap+0x24e/0x2d0 mm/mmap.c:2741
mmap_region+0x729/0x2020 mm/mmap.c:2792
do_mmap+0x8ad/0xf70 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x53c/0x6e0 mm/mmap.c:1433
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88807c6434d8
which belongs to the cache vm_area_struct of size 184
The buggy address is located 32 bytes inside of
freed 184-byte region [ffff88807c6434d8, ffff88807c643590)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88807c643aa8 pfn:0x7c643
memcg:ffff88802cfea301
anon flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff8880162a7b40 ffffea00017aa380 dead000000000005
raw: ffff88807c643aa8 000000000010000b 00000001ffffefff ffff88802cfea301
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 8361, tgid -847542916 (dhcpcd-run-hook), ts 8361, free_ts 221237227404
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1468
prep_new_page mm/page_alloc.c:1476 [inline]
get_page_from_freelist+0x2ce2/0x2d90 mm/page_alloc.c:3438
__alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4696
__alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
alloc_slab_page+0x5f/0x120 mm/slub.c:2259
allocate_slab+0x5a/0x2e0 mm/slub.c:2422
new_slab mm/slub.c:2475 [inline]
___slab_alloc+0xcd1/0x14b0 mm/slub.c:3624
__slab_alloc+0x58/0xa0 mm/slub.c:3714
__slab_alloc_node mm/slub.c:3767 [inline]
slab_alloc_node mm/slub.c:3945 [inline]
kmem_cache_alloc_noprof+0x1c1/0x290 mm/slub.c:3964
vm_area_dup+0x27/0x290 kernel/fork.c:482
dup_mmap kernel/fork.c:697 [inline]
dup_mm kernel/fork.c:1687 [inline]
copy_mm+0xd0f/0x1fd0 kernel/fork.c:1736
copy_process+0x187a/0x3dc0 kernel/fork.c:2389
kernel_clone+0x226/0x8f0 kernel/fork.c:2796
__do_sys_clone kernel/fork.c:2939 [inline]
__se_sys_clone kernel/fork.c:2923 [inline]
__x64_sys_clone+0x258/0x2a0 kernel/fork.c:2923
do_syscall_64+0xfb/0x240
entry_SYSCALL_64_after_hwframe+0x72/0x7a
page last free pid 5098 tgid 5098 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1088 [inline]
free_unref_folios+0xf23/0x19e0 mm/page_alloc.c:2650
folios_put_refs+0x93a/0xa60 mm/swap.c:1022
folio_batch_release include/linux/pagevec.h:101 [inline]
invalidate_inode_pages2_range+0xdfa/0x10e0 mm/truncate.c:670
close_ctree+0x673/0xd20 fs/btrfs/disk-io.c:4367
generic_shutdown_super+0x136/0x2d0 fs/super.c:641
kill_anon_super+0x3b/0x70 fs/super.c:1225
btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2091
deactivate_locked_super+0xc4/0x130 fs/super.c:472
cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
task_work_run+0x24f/0x310 kernel/task_work.c:180
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
exit_to_user_mode_loop kernel/entry/common.c:114 [inline]
exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218
do_syscall_64+0x10a/0x240 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x72/0x7a
Memory state around the buggy address:
ffff88807c643380: fb fb fb fb fc fc fc fc fc fc fc fc fa fb fb fb
ffff88807c643400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88807c643480: fb fb fb fc fc fc fc fc fc fc fc fa fb fb fb fb
^
ffff88807c643500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807c643580: fb fb fc fc fc fc fc fc fc fc fa fb fb fb fb fb
==================================================================
---
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 [email protected].
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 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
syzbot has found a reproducer for the following issue on:
HEAD commit: 9ed46da14b9b Add linux-next specific files for 20240412
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12bd4457180000
kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
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=1370ea67180000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/fc649744d68c/disk-9ed46da1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/11eab7b9945d/vmlinux-9ed46da1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e7885afd198d/bzImage-9ed46da1.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/52aaf544deaa/mount_1.gz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
==================================================================
BUG: KASAN: slab-use-after-free in is_vm_hugetlb_page include/linux/hugetlb_inline.h:11 [inline]
BUG: KASAN: slab-use-after-free in vma_resv_map mm/hugetlb.c:1150 [inline]
BUG: KASAN: slab-use-after-free in __vma_reservation_common+0xc9/0x7d0 mm/hugetlb.c:2807
Read of size 8 at addr ffff888077a2f4f8 by task syz-executor.1/5375
CPU: 0 PID: 5375 Comm: syz-executor.1 Not tainted 6.9.0-rc3-next-20240412-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
is_vm_hugetlb_page include/linux/hugetlb_inline.h:11 [inline]
vma_resv_map mm/hugetlb.c:1150 [inline]
__vma_reservation_common+0xc9/0x7d0 mm/hugetlb.c:2807
vma_needs_reservation mm/hugetlb.c:2881 [inline]
restore_reserve_on_error+0x39/0x1d0 mm/hugetlb.c:2931
hugetlb_no_page mm/hugetlb.c:6391 [inline]
hugetlb_fault+0x1ae1/0x3910 mm/hugetlb.c:6487
handle_mm_fault+0x18e8/0x1bb0 mm/memory.c:5701
do_user_addr_fault arch/x86/mm/fault.c:1368 [inline]
handle_page_fault arch/x86/mm/fault.c:1511 [inline]
exc_page_fault+0x459/0x900 arch/x86/mm/fault.c:1569
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0033:0x7f0abea29681
Code: 39 c6 7e 57 4c 8b 5f 20 48 8b 57 28 eb 06 0f 1f 00 4c 89 c2 49 39 d3 74 47 4c 8b 57 18 4c 8d 42 01 89 c1 83 c0 08 4c 89 47 28 <41> 0f b6 14 12 89 47 34 48 d3 e2 49 09 d1 39 f0 7c d5 44 89 ca 29
RSP: 002b:00007f0abf824578 EFLAGS: 00010202
RAX: 0000000000000008 RBX: 00007f0abf824eb8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00007f0abf824670
RBP: 00007f0abf824670 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020001602 R11: 000000000000609f R12: 0000000000000003
R13: 00007f0abf824f80 R14: 00007f0abf824f40 R15: 00007f0ab5800000
</TASK>
Allocated by task 5373:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3897 [inline]
slab_alloc_node mm/slub.c:3957 [inline]
kmem_cache_alloc_noprof+0x135/0x290 mm/slub.c:3964
vm_area_alloc+0x24/0x1d0 kernel/fork.c:467
mmap_region+0xc20/0x2030 mm/mmap.c:2852
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x544/0x720 mm/mmap.c:1433
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 16:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2190 [inline]
slab_free mm/slub.c:4393 [inline]
kmem_cache_free+0x145/0x340 mm/slub.c:4468
rcu_do_batch kernel/rcu/tree.c:2565 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2839
__do_softirq+0x2c6/0x980 kernel/softirq.c:554
Last potentially related work creation:
kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
__kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
__call_rcu_common kernel/rcu/tree.c:3102 [inline]
call_rcu+0x167/0xa70 kernel/rcu/tree.c:3206
remove_vma mm/mmap.c:148 [inline]
remove_mt mm/mmap.c:2334 [inline]
do_vmi_align_munmap+0x155c/0x18c0 mm/mmap.c:2677
do_vmi_munmap+0x24e/0x2d0 mm/mmap.c:2741
mmap_region+0x729/0x2030 mm/mmap.c:2792
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x544/0x720 mm/mmap.c:1433
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888077a2f4d8
which belongs to the cache vm_area_struct of size 184
The buggy address is located 32 bytes inside of
freed 184-byte region [ffff888077a2f4d8, ffff888077a2f590)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x77a2f
memcg:ffff88801a6ca701
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff8880162a7b40 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000100010 00000001ffffefff ffff88801a6ca701
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 5359, tgid 1476644483 (syz-executor.2), ts 5362, free_ts 103330549507
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1474
prep_new_page mm/page_alloc.c:1482 [inline]
get_page_from_freelist+0x2ce2/0x2d90 mm/page_alloc.c:3444
__alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4702
__alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
alloc_slab_page+0x5f/0x120 mm/slub.c:2259
allocate_slab+0x5a/0x2e0 mm/slub.c:2422
new_slab mm/slub.c:2475 [inline]
___slab_alloc+0xcd1/0x14b0 mm/slub.c:3624
__slab_alloc+0x58/0xa0 mm/slub.c:3714
__slab_alloc_node mm/slub.c:3767 [inline]
slab_alloc_node mm/slub.c:3945 [inline]
kmem_cache_alloc_noprof+0x1c1/0x290 mm/slub.c:3964
vm_area_alloc+0x24/0x1d0 kernel/fork.c:467
mmap_region+0xc20/0x2030 mm/mmap.c:2852
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5295 tgid 5292 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1094 [inline]
free_unref_folios+0xf23/0x19e0 mm/page_alloc.c:2656
folios_put_refs+0x93a/0xa60 mm/swap.c:1022
free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:332
__tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]
tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]
tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373
tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465
exit_mmap+0x44f/0xc80 mm/mmap.c:3325
__mmput+0x115/0x3c0 kernel/fork.c:1346
exit_mm+0x220/0x310 kernel/exit.c:569
do_exit+0x99e/0x27e0 kernel/exit.c:865
do_group_exit+0x207/0x2c0 kernel/exit.c:1027
get_signal+0x16a1/0x1740 kernel/signal.c:2911
arch_do_signal_or_restart+0x96/0x860 arch/x86/kernel/signal.c:310
exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
syscall_exit_to_user_mode+0xc9/0x370 kernel/entry/common.c:218
do_syscall_64+0x10a/0x250 arch/x86/entry/common.c:111
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff888077a2f380: fb fb fb fb fc fc fc fc fc fc fc fc fa fb fb fb
ffff888077a2f400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888077a2f480: fb fb fb fc fc fc fc fc fc fc fc fa fb fb fb fb
^
ffff888077a2f500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888077a2f580: fb fb fc fc fc fc fc fc fc fc fa fb fb fb fb fb
==================================================================
---
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.
On Sat, 13 Apr 2024 11:34:32 -0700
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 9ed46da14b9b Add linux-next specific files for 20240412
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12bd4457180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> 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=1370ea67180000
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 9ed46da14b9b
--- x/mm/mmap.c
+++ y/mm/mmap.c
@@ -2657,8 +2657,6 @@ do_vmi_align_munmap(struct vma_iterator
/* Point of no return */
mm->locked_vm -= locked_vm;
mm->map_count -= count;
- if (unlock)
- mmap_write_downgrade(mm);
prev = vma_iter_prev_range(vmi);
next = vma_next(vmi);
@@ -2677,7 +2675,7 @@ do_vmi_align_munmap(struct vma_iterator
remove_mt(mm, &mas_detach);
validate_mm(mm);
if (unlock)
- mmap_read_unlock(mm);
+ mmap_write_unlock(mm);
__mt_destroy(&mt_detach);
return 0;
--
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-use-after-free Read in hugetlb_fault
==================================================================
BUG: KASAN: slab-use-after-free in __vma_shareable_lock include/linux/hugetlb.h:1273 [inline]
BUG: KASAN: slab-use-after-free in hugetlb_vma_unlock_read mm/hugetlb.c:281 [inline]
BUG: KASAN: slab-use-after-free in hugetlb_no_page mm/hugetlb.c:6383 [inline]
BUG: KASAN: slab-use-after-free in hugetlb_fault+0x27b9/0x3910 mm/hugetlb.c:6487
Read of size 8 at addr ffff88801eda2ea8 by task syz-executor.0/6040
CPU: 0 PID: 6040 Comm: syz-executor.0 Not tainted 6.9.0-rc3-next-20240412-syzkaller-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488
kasan_report+0x143/0x180 mm/kasan/report.c:601
__vma_shareable_lock include/linux/hugetlb.h:1273 [inline]
hugetlb_vma_unlock_read mm/hugetlb.c:281 [inline]
hugetlb_no_page mm/hugetlb.c:6383 [inline]
hugetlb_fault+0x27b9/0x3910 mm/hugetlb.c:6487
handle_mm_fault+0x18e8/0x1bb0 mm/memory.c:5701
do_user_addr_fault arch/x86/mm/fault.c:1368 [inline]
handle_page_fault arch/x86/mm/fault.c:1511 [inline]
exc_page_fault+0x459/0x900 arch/x86/mm/fault.c:1569
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
RIP: 0033:0x7fe7d8a5eeeb
Code: fa 10 73 2d 83 fa 08 73 46 83 fa 04 73 16 83 fa 01 7c 10 8a 0e 74 0a 0f b7 74 16 fe 66 89 74 17 fe 88 0f c3 8b 4c 16 fc 8b 36 <89> 4c 17 fc 89 37 c3 c5 fa 6f 06 c5 fa 6f 4c 16 f0 c5 fa 7f 07 c5
RSP: 002b:00007ffd32a0d108 EFLAGS: 00010246
RAX: 0000000020000700 RBX: 00007ffd32a0d218 RCX: 000000000073666a
RDX: 0000000000000004 RSI: 000000000073666a RDI: 0000000020000700
RBP: 0000000000000048 R08: 00007fe7d8a00000 R09: 00007fe7d8babf8c
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe7d86000c8
R13: fffffffffffffffe R14: 00007fe7d8600000 R15: 00007fe7d86000d0
</TASK>
Allocated by task 6043:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
unpoison_slab_object mm/kasan/common.c:312 [inline]
__kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
kasan_slab_alloc include/linux/kasan.h:201 [inline]
slab_post_alloc_hook mm/slub.c:3897 [inline]
slab_alloc_node mm/slub.c:3957 [inline]
kmem_cache_alloc_noprof+0x135/0x290 mm/slub.c:3964
vm_area_alloc+0x24/0x1d0 kernel/fork.c:467
mmap_region+0xc20/0x2030 mm/mmap.c:2850
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x544/0x720 mm/mmap.c:1433
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6043:
kasan_save_stack mm/kasan/common.c:47 [inline]
kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
__kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2190 [inline]
slab_free mm/slub.c:4393 [inline]
kmem_cache_free+0x145/0x340 mm/slub.c:4468
rcu_do_batch kernel/rcu/tree.c:2565 [inline]
rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2839
__do_softirq+0x2c6/0x980 kernel/softirq.c:554
Last potentially related work creation:
kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
__kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
__call_rcu_common kernel/rcu/tree.c:3102 [inline]
call_rcu+0x167/0xa70 kernel/rcu/tree.c:3206
remove_vma mm/mmap.c:148 [inline]
remove_mt mm/mmap.c:2334 [inline]
do_vmi_align_munmap+0x14b6/0x1870 mm/mmap.c:2675
do_vmi_munmap+0x24e/0x2d0 mm/mmap.c:2739
mmap_region+0x729/0x2030 mm/mmap.c:2790
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x544/0x720 mm/mmap.c:1433
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff88801eda2e88
which belongs to the cache vm_area_struct of size 184
The buggy address is located 32 bytes inside of
freed 184-byte region [ffff88801eda2e88, ffff88801eda2f40)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eda2
memcg:ffff88801ee05801
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff8880162a7b40 ffffea0000899500 dead000000000004
raw: 0000000000000000 0000000000100010 00000001ffffefff ffff88801ee05801
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 5030, tgid -2004887359 (sftp-server), ts 5030, free_ts 49525412931
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1474
prep_new_page mm/page_alloc.c:1482 [inline]
get_page_from_freelist+0x2ce2/0x2d90 mm/page_alloc.c:3444
__alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4702
__alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
alloc_slab_page+0x5f/0x120 mm/slub.c:2259
allocate_slab+0x5a/0x2e0 mm/slub.c:2422
new_slab mm/slub.c:2475 [inline]
___slab_alloc+0xcd1/0x14b0 mm/slub.c:3624
__slab_alloc+0x58/0xa0 mm/slub.c:3714
__slab_alloc_node mm/slub.c:3767 [inline]
slab_alloc_node mm/slub.c:3945 [inline]
kmem_cache_alloc_noprof+0x1c1/0x290 mm/slub.c:3964
vm_area_alloc+0x24/0x1d0 kernel/fork.c:467
mmap_region+0xc20/0x2030 mm/mmap.c:2850
do_mmap+0x8ad/0xfa0 mm/mmap.c:1387
vm_mmap_pgoff+0x1dd/0x3d0 mm/util.c:573
ksys_mmap_pgoff+0x4f1/0x720 mm/mmap.c:1433
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5030 tgid 5030 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1094 [inline]
free_unref_folios+0xf23/0x19e0 mm/page_alloc.c:2656
folios_put_refs+0x93a/0xa60 mm/swap.c:1022
free_pages_and_swap_cache+0x2ea/0x690 mm/swap_state.c:329
__tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]
tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]
tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]
tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373
tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465
exit_mmap+0x44f/0xc80 mm/mmap.c:3323
__mmput+0x115/0x3c0 kernel/fork.c:1346
exec_mmap+0x69d/0x730 fs/exec.c:1063
begin_new_exec+0x125f/0x1f50 fs/exec.c:1329
load_elf_binary+0x97d/0x25a0 fs/binfmt_elf.c:996
search_binary_handler fs/exec.c:1797 [inline]
exec_binprm fs/exec.c:1839 [inline]
bprm_execve+0xaf8/0x17c0 fs/exec.c:1891
do_execveat_common+0x553/0x700 fs/exec.c:1998
do_execve fs/exec.c:2072 [inline]
__do_sys_execve fs/exec.c:2148 [inline]
__se_sys_execve fs/exec.c:2143 [inline]
__x64_sys_execve+0x92/0xb0 fs/exec.c:2143
do_syscall_x64 arch/x86/entry/common.c:74 [inline]
do_syscall_64+0xfa/0x250 arch/x86/entry/common.c:105
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff88801eda2d80: fc fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801eda2e00: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
>ffff88801eda2e80: fc fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88801eda2f00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff88801eda2f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Tested on:
commit: 9ed46da1 Add linux-next specific files for 20240412
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=10766467180000
kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=126b7a77180000
On Sat, 13 Apr 2024 11:34:32 -0700
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 9ed46da14b9b Add linux-next specific files for 20240412
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12bd4457180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> 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=1370ea67180000
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 9ed46da14b9b
--- x/arch/x86/mm/fault.c
+++ y/arch/x86/mm/fault.c
@@ -1353,8 +1353,7 @@ void do_user_addr_fault(struct pt_regs *
}
#endif
- if (!(flags & FAULT_FLAG_USER))
- goto lock_mmap;
+ goto lock_mmap;
vma = lock_vma_under_rcu(mm, address);
if (!vma)
--
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
Tested on:
commit: 9ed46da1 Add linux-next specific files for 20240412
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=17d54961180000
kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=118851eb180000
Note: testing is done by a robot and is best-effort only.
On Sat, Apr 13, 2024 at 11:34:32AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 9ed46da14b9b Add linux-next specific files for 20240412
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12bd4457180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> 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=1370ea67180000
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 9ed46da14b9b
On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote:
> Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
> anon_vma_prepare()") may bailout after allocating a folio if we do not
> hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
> vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
> which depends on the vma lock being held.
>
> We can move vmf_anon_prepare() prior to the folio allocation in order to
> avoid calling restore_reserve_on_error() without the vma lock.
But now you're calling vmf_anon_prepare() in the wrong place -- before
we've determined that we need an anon folio. So we'll create an
anon_vma even when we don't need one for this vma.
This is definitely a pre-existing bug which you've exposed by making it
happen more easily. Needs a different fix though.
On Mon, Apr 15, 2024 at 3:15 PM Matthew Wilcox <[email protected]> wrote:
>
> On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote:
> > Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
> > anon_vma_prepare()") may bailout after allocating a folio if we do not
> > hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
> > vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
> > which depends on the vma lock being held.
> >
> > We can move vmf_anon_prepare() prior to the folio allocation in order to
> > avoid calling restore_reserve_on_error() without the vma lock.
>
> But now you're calling vmf_anon_prepare() in the wrong place -- before
> we've determined that we need an anon folio. So we'll create an
> anon_vma even when we don't need one for this vma.
That's true. Though that can be addressed through something like:
if (!(vma->vm_flags & VM_MAYSHARE)) {
ret = vmf_anon_prepare(vmf);
if (unlikely(ret))
goto out;
}
> This is definitely a pre-existing bug which you've exposed by making it
> happen more easily. Needs a different fix though.
I interpreted the bug report to showcase how restore_reserve_on_error()
depends on the vma lock being held - and vmf_anon_prepare() drops that
lock by the time we get to restore_reserve_on_error(). In this case, this
would address it without reworking restore_reserve_on_error().
There very well could be something completely different going on, however
I have no ideas as to what that may be.
On Mon, Apr 15, 2024 at 04:02:48PM -0700, Vishal Moola wrote:
> On Mon, Apr 15, 2024 at 3:15 PM Matthew Wilcox <[email protected]> wrote:
> >
> > On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote:
> > > Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
> > > anon_vma_prepare()") may bailout after allocating a folio if we do not
> > > hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
> > > vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
> > > which depends on the vma lock being held.
> > >
> > > We can move vmf_anon_prepare() prior to the folio allocation in order to
> > > avoid calling restore_reserve_on_error() without the vma lock.
> >
> > But now you're calling vmf_anon_prepare() in the wrong place -- before
> > we've determined that we need an anon folio. So we'll create an
> > anon_vma even when we don't need one for this vma.
>
> That's true. Though that can be addressed through something like:
>
> if (!(vma->vm_flags & VM_MAYSHARE)) {
> ret = vmf_anon_prepare(vmf);
> if (unlikely(ret))
> goto out;
> }
Why does hugetlbfs use VM_MAYSHARE while regular faults use VM_SHARED?
On Tue, Apr 16, 2024 at 05:35:50AM +0100, Matthew Wilcox wrote:
> Why does hugetlbfs use VM_MAYSHARE while regular faults use VM_SHARED?
It goes back to:
commit f83a275dbc5ca1721143698e844243fcadfabf6a
Author: Mel Gorman <[email protected]>
Date: Thu May 28 14:34:40 2009 -0700
mm: account for MAP_SHARED mappings using VM_MAYSHARE and not VM_SHARED in hugetlbfs
"hugetlbfs currently checks if a VMA is MAP_SHARED with the VM_SHARED flag
and not VM_MAYSHARE. For file-backed mappings, such as hugetlbfs,
VM_SHARED is set only if the mapping is MAP_SHARED and the file was opened
read-write. If a shared memory mapping was mapped shared-read-write for
populating of data and mapped shared-read-only by other processes, then
hugetlbfs would account for the mapping as if it was MAP_PRIVATE. This
causes processes to fail to map the file MAP_SHARED even though it should
succeed as the reservation is there."
--
Oscar Salvador
SUSE Labs
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-and-tested-by: [email protected]
Tested on:
commit: 9ed46da1 Add linux-next specific files for 20240412
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
console output: https://syzkaller.appspot.com/x/log.txt?x=15f0023b180000
kernel config: https://syzkaller.appspot.com/x/.config?x=7ea0abc478c49859
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=1065003b180000
Note: testing is done by a robot and is best-effort only.
On Mon, Apr 15, 2024 at 11:15:03PM +0100, Matthew Wilcox wrote:
> On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote:
> > Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
> > anon_vma_prepare()") may bailout after allocating a folio if we do not
> > hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
> > vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
> > which depends on the vma lock being held.
> >
> > We can move vmf_anon_prepare() prior to the folio allocation in order to
> > avoid calling restore_reserve_on_error() without the vma lock.
>
> But now you're calling vmf_anon_prepare() in the wrong place -- before
> we've determined that we need an anon folio. So we'll create an
> anon_vma even when we don't need one for this vma.
>
> This is definitely a pre-existing bug which you've exposed by making it
> happen more easily. Needs a different fix though.
I do not think this is a pre-existing bug.
Prior to 'commit: 7c43a553792a ("hugetlb: allow faults to be handled under
the VMA lock"), we would just bail out if we had FAULT_FLAG_VMA_LOCK.
So there was no danger in calling functions that fiddle with vmas like
restore_reserve_on_error() does.
After that, we allow it but vmf_anon_prepare() releases the lock and returns
VM_FAULT_RETRY if we really need to allocate an anon_vma.
The problem is that now restore_reserve_on_error() will re-adjust the
reservations without the vma lock, completely unsafe.
I think the safest way to tackle this is just as Vishal did, call
vmf_anon_prepare() upfront only for non VM_MAYSHARE faults.
--
Oscar Salvador
SUSE Labs
On Tue, 16 Apr 2024 10:13:31 +0200 Oscar Salvador <[email protected]> wrote:
> On Mon, Apr 15, 2024 at 11:15:03PM +0100, Matthew Wilcox wrote:
> > On Mon, Apr 15, 2024 at 03:05:44PM -0700, Vishal Moola wrote:
> > > Commit 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of
> > > anon_vma_prepare()") may bailout after allocating a folio if we do not
> > > hold the mmap lock. When this occurs, vmf_anon_prepare() will release the
> > > vma lock. Hugetlb then attempts to call restore_reserve_on_error(),
> > > which depends on the vma lock being held.
> > >
> > > We can move vmf_anon_prepare() prior to the folio allocation in order to
> > > avoid calling restore_reserve_on_error() without the vma lock.
> >
> > But now you're calling vmf_anon_prepare() in the wrong place -- before
> > we've determined that we need an anon folio. So we'll create an
> > anon_vma even when we don't need one for this vma.
> >
> > This is definitely a pre-existing bug which you've exposed by making it
> > happen more easily. Needs a different fix though.
>
> I do not think this is a pre-existing bug.
> Prior to 'commit: 7c43a553792a ("hugetlb: allow faults to be handled under
> the VMA lock"), we would just bail out if we had FAULT_FLAG_VMA_LOCK.
> So there was no danger in calling functions that fiddle with vmas like
> restore_reserve_on_error() does.
> After that, we allow it but vmf_anon_prepare() releases the lock and returns
> VM_FAULT_RETRY if we really need to allocate an anon_vma.
> The problem is that now restore_reserve_on_error() will re-adjust the
> reservations without the vma lock, completely unsafe.
>
> I think the safest way to tackle this is just as Vishal did, call
> vmf_anon_prepare() upfront only for non VM_MAYSHARE faults.
Thanks. I didn't apply anything at this stage, because this patch
appears to be against linux-next/mm-unstable whereas for a -stable
backportable thing it would best be against current -linus.
So can we please sort out a suitable Fixes:, redo the patch against
current mainline, add the cc:stable and await further input from
Matthew?
On Fri, Apr 12, 2024 at 06:32:33AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 11cb68ad52ac Add linux-next specific files for 20240408
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a6f483180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=727d5608101b5d77
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/4e90f2d3b1ef/disk-11cb68ad.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/d886b454e2cc/vmlinux-11cb68ad.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/ed94857c6f92/bzImage-11cb68ad.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
linus
> On Fri, Apr 12, 2024 at 06:32:33AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 11cb68ad52ac Add linux-next specific files for 20240408
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13a6f483180000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=727d5608101b5d77
>> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
>> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/4e90f2d3b1ef/disk-11cb68ad.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/d886b454e2cc/vmlinux-11cb68ad.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/ed94857c6f92/bzImage-11cb68ad.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: [email protected]
>
> #syz test https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
want either no args or 2 args (repo, branch), got 1
> linus
On Fri, Apr 12, 2024 at 06:32:33AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 11cb68ad52ac Add linux-next specific files for 20240408
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13a6f483180000
> kernel config: https://syzkaller.appspot.com/x/.config?x=727d5608101b5d77
> dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/4e90f2d3b1ef/disk-11cb68ad.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/d886b454e2cc/vmlinux-11cb68ad.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/ed94857c6f92/bzImage-11cb68ad.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
#syz test https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git linus
Hello,
syzbot tried to test the proposed patch but the build/boot failed:
: registered new interface driver rtsx_usb
[ 7.671002][ T1] usbcore: registered new interface driver viperboard
[ 7.672903][ T1] usbcore: registered new interface driver dln2
[ 7.674419][ T1] usbcore: registered new interface driver pn533_usb
[ 7.681042][ T1] nfcsim 0.2 initialized
[ 7.681871][ T1] usbcore: registered new interface driver port100
[ 7.683273][ T1] usbcore: registered new interface driver nfcmrvl
[ 7.690221][ T1] Loading iSCSI transport class v2.0-870.
[ 7.709703][ T1] virtio_scsi virtio0: 1/0/0 default/read/poll queues
[ 7.720575][ T1] ------------[ cut here ]------------
[ 7.721959][ T1] refcount_t: decrement hit 0; leaking memory.
[ 7.723401][ T1] WARNING: CPU: 0 PID: 1 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0
[ 7.725405][ T1] Modules linked in:
[ 7.726102][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4-syzkaller-00031-g96fca68c4fbf-dirty #0
[ 7.727850][ T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
[ 7.729277][ T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[ 7.730342][ T1] Code: b2 00 00 00 e8 07 05 e7 fc 5b 5d c3 cc cc cc cc e8 fb 04 e7 fc c6 05 d9 7d e4 0a 01 90 48 c7 c7 40 33 1f 8c e8 67 81 a9 fc 90 <0f> 0b 90 90 eb d9 e8 db 04 e7 fc c6 05 b6 7d e4 0a 01 90 48 c7 c7
[ 7.733682][ T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[ 7.734579][ T1] RAX: 4c11f4fbdf346600 RBX: ffff888020cfe13c RCX: ffff8880166d0000
[ 7.736062][ T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 7.737626][ T1] RBP: 0000000000000004 R08: ffffffff815880a2 R09: fffffbfff1c39b48
[ 7.738967][ T1] R10: dffffc0000000000 R11: fffffbfff1c39b48 R12: ffffea000502cdc0
[ 7.740234][ T1] R13: ffffea000502cdc8 R14: 1ffffd4000a059b9 R15: 0000000000000000
[ 7.741505][ T1] FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
[ 7.743319][ T1] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7.744266][ T1] CR2: ffff88823ffff000 CR3: 000000000e134000 CR4: 00000000003506f0
[ 7.745934][ T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 7.747137][ T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 7.748484][ T1] Call Trace:
[ 7.749033][ T1] <TASK>
[ 7.749520][ T1] ? __warn+0x163/0x4e0
[ 7.750519][ T1] ? refcount_warn_saturate+0xfa/0x1d0
[ 7.751478][ T1] ? report_bug+0x2b3/0x500
[ 7.752127][ T1] ? refcount_warn_saturate+0xfa/0x1d0
[ 7.752989][ T1] ? handle_bug+0x3e/0x70
[ 7.753676][ T1] ? exc_invalid_op+0x1a/0x50
[ 7.754367][ T1] ? asm_exc_invalid_op+0x1a/0x20
[ 7.755231][ T1] ? __warn_printk+0x292/0x360
[ 7.756237][ T1] ? refcount_warn_saturate+0xfa/0x1d0
[ 7.757213][ T1] ? refcount_warn_saturate+0xf9/0x1d0
[ 7.758709][ T1] __free_pages_ok+0xc60/0xd90
[ 7.759783][ T1] make_alloc_exact+0xa3/0xf0
[ 7.760537][ T1] vring_alloc_queue_split+0x20a/0x600
[ 7.761574][ T1] ? __pfx_vring_alloc_queue_split+0x10/0x10
[ 7.762858][ T1] ? vp_find_vqs+0x4c/0x4e0
[ 7.764032][ T1] ? virtscsi_probe+0x3ea/0xf60
[ 7.765068][ T1] ? virtio_dev_probe+0x991/0xaf0
[ 7.766076][ T1] ? really_probe+0x2b8/0xad0
[ 7.766989][ T1] ? driver_probe_device+0x50/0x430
[ 7.767862][ T1] vring_create_virtqueue_split+0xc6/0x310
[ 7.768991][ T1] ? ret_from_fork+0x4b/0x80
[ 7.769824][ T1] ? __pfx_vring_create_virtqueue_split+0x10/0x10
[ 7.770902][ T1] vring_create_virtqueue+0xca/0x110
[ 7.771856][ T1] ? __pfx_vp_notify+0x10/0x10
[ 7.772808][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.773886][ T1] setup_vq+0xe9/0x2d0
[ 7.774638][ T1] ? __pfx_vp_notify+0x10/0x10
[ 7.775418][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.776418][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.777523][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.778656][ T1] vp_setup_vq+0xbf/0x330
[ 7.779318][ T1] ? __pfx_vp_config_changed+0x10/0x10
[ 7.780244][ T1] ? ioread16+0x2f/0x90
[ 7.780897][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.781822][ T1] vp_find_vqs_msix+0x8b2/0xc80
[ 7.782771][ T1] vp_find_vqs+0x4c/0x4e0
[ 7.783720][ T1] virtscsi_init+0x8db/0xd00
[ 7.784741][ T1] ? __pfx_virtscsi_init+0x10/0x10
[ 7.785550][ T1] ? __pfx_default_calc_sets+0x10/0x10
[ 7.786659][ T1] ? scsi_host_alloc+0xa57/0xea0
[ 7.787673][ T1] ? vp_get+0xfd/0x140
[ 7.788473][ T1] virtscsi_probe+0x3ea/0xf60
[ 7.789468][ T1] ? __pfx_virtscsi_probe+0x10/0x10
[ 7.790246][ T1] ? kernfs_add_one+0x156/0x8b0
[ 7.791590][ T1] ? virtio_no_restricted_mem_acc+0x9/0x10
[ 7.793149][ T1] ? virtio_features_ok+0x10c/0x270
[ 7.794179][ T1] virtio_dev_probe+0x991/0xaf0
[ 7.795928][ T1] ? __pfx_virtio_dev_probe+0x10/0x10
[ 7.796830][ T1] really_probe+0x2b8/0xad0
[ 7.797762][ T1] __driver_probe_device+0x1a2/0x390
[ 7.799008][ T1] driver_probe_device+0x50/0x430
[ 7.800080][ T1] __driver_attach+0x45f/0x710
[ 7.800982][ T1] ? __pfx___driver_attach+0x10/0x10
[ 7.802135][ T1] bus_for_each_dev+0x239/0x2b0
[ 7.803466][ T1] ? __pfx___driver_attach+0x10/0x10
[ 7.804685][ T1] ? __pfx_bus_for_each_dev+0x10/0x10
[ 7.805788][ T1] ? do_raw_spin_unlock+0x13c/0x8b0
[ 7.807328][ T1] bus_add_driver+0x347/0x620
[ 7.808200][ T1] driver_register+0x23a/0x320
[ 7.808976][ T1] virtio_scsi_init+0x69/0xe0
[ 7.809707][ T1] ? __pfx_virtio_scsi_init+0x10/0x10
[ 7.811269][ T1] do_one_initcall+0x248/0x880
[ 7.812854][ T1] ? __pfx_virtio_scsi_init+0x10/0x10
[ 7.813969][ T1] ? __pfx_do_one_initcall+0x10/0x10
[ 7.815128][ T1] ? lockdep_hardirqs_on_prepare+0x43d/0x780
[ 7.816629][ T1] ? __pfx_parse_args+0x10/0x10
[ 7.817705][ T1] ? do_initcalls+0x1c/0x80
[ 7.818397][ T1] ? rcu_is_watching+0x15/0xb0
[ 7.819245][ T1] do_initcall_level+0x157/0x210
[ 7.820362][ T1] do_initcalls+0x3f/0x80
[ 7.821273][ T1] kernel_init_freeable+0x435/0x5d0
[ 7.822360][ T1] ? __pfx_kernel_init_freeable+0x10/0x10
[ 7.824148][ T1] ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[ 7.825527][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.826406][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.827457][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.828321][ T1] kernel_init+0x1d/0x2b0
[ 7.829196][ T1] ret_from_fork+0x4b/0x80
[ 7.829955][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.830754][ T1] ret_from_fork_asm+0x1a/0x30
[ 7.832029][ T1] </TASK>
[ 7.832583][ T1] Kernel panic - not syncing: kernel: panic_on_warn set ...
[ 7.833890][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4-syzkaller-00031-g96fca68c4fbf-dirty #0
[ 7.835440][ T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
[ 7.835440][ T1] Call Trace:
[ 7.835440][ T1] <TASK>
[ 7.835440][ T1] dump_stack_lvl+0x241/0x360
[ 7.835440][ T1] ? __pfx_dump_stack_lvl+0x10/0x10
[ 7.835440][ T1] ? __pfx__printk+0x10/0x10
[ 7.835440][ T1] ? _printk+0xd5/0x120
[ 7.835440][ T1] ? vscnprintf+0x5d/0x90
[ 7.835440][ T1] panic+0x349/0x860
[ 7.835440][ T1] ? __warn+0x172/0x4e0
[ 7.845404][ T1] ? __pfx_panic+0x10/0x10
[ 7.845404][ T1] ? show_trace_log_lvl+0x4e6/0x520
[ 7.845404][ T1] ? ret_from_fork_asm+0x1a/0x30
[ 7.845404][ T1] __warn+0x346/0x4e0
[ 7.845404][ T1] ? refcount_warn_saturate+0xfa/0x1d0
[ 7.845404][ T1] report_bug+0x2b3/0x500
[ 7.845404][ T1] ? refcount_warn_saturate+0xfa/0x1d0
[ 7.845404][ T1] handle_bug+0x3e/0x70
[ 7.845404][ T1] exc_invalid_op+0x1a/0x50
[ 7.855352][ T1] asm_exc_invalid_op+0x1a/0x20
[ 7.855352][ T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[ 7.855352][ T1] Code: b2 00 00 00 e8 07 05 e7 fc 5b 5d c3 cc cc cc cc e8 fb 04 e7 fc c6 05 d9 7d e4 0a 01 90 48 c7 c7 40 33 1f 8c e8 67 81 a9 fc 90 <0f> 0b 90 90 eb d9 e8 db 04 e7 fc c6 05 b6 7d e4 0a 01 90 48 c7 c7
[ 7.855352][ T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[ 7.855352][ T1] RAX: 4c11f4fbdf346600 RBX: ffff888020cfe13c RCX: ffff8880166d0000
[ 7.855352][ T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 7.865369][ T1] RBP: 0000000000000004 R08: ffffffff815880a2 R09: fffffbfff1c39b48
[ 7.865369][ T1] R10: dffffc0000000000 R11: fffffbfff1c39b48 R12: ffffea000502cdc0
[ 7.865369][ T1] R13: ffffea000502cdc8 R14: 1ffffd4000a059b9 R15: 0000000000000000
[ 7.865369][ T1] ? __warn_printk+0x292/0x360
[ 7.865369][ T1] ? refcount_warn_saturate+0xf9/0x1d0
[ 7.865369][ T1] __free_pages_ok+0xc60/0xd90
[ 7.865369][ T1] make_alloc_exact+0xa3/0xf0
[ 7.875273][ T1] vring_alloc_queue_split+0x20a/0x600
[ 7.875273][ T1] ? __pfx_vring_alloc_queue_split+0x10/0x10
[ 7.875273][ T1] ? vp_find_vqs+0x4c/0x4e0
[ 7.875273][ T1] ? virtscsi_probe+0x3ea/0xf60
[ 7.875273][ T1] ? virtio_dev_probe+0x991/0xaf0
[ 7.875273][ T1] ? really_probe+0x2b8/0xad0
[ 7.875273][ T1] ? driver_probe_device+0x50/0x430
[ 7.875273][ T1] vring_create_virtqueue_split+0xc6/0x310
[ 7.875273][ T1] ? ret_from_fork+0x4b/0x80
[ 7.875273][ T1] ? __pfx_vring_create_virtqueue_split+0x10/0x10
[ 7.885398][ T1] vring_create_virtqueue+0xca/0x110
[ 7.885398][ T1] ? __pfx_vp_notify+0x10/0x10
[ 7.885398][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.885398][ T1] setup_vq+0xe9/0x2d0
[ 7.885398][ T1] ? __pfx_vp_notify+0x10/0x10
[ 7.885398][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.885398][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.885398][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.885398][ T1] vp_setup_vq+0xbf/0x330
[ 7.895327][ T1] ? __pfx_vp_config_changed+0x10/0x10
[ 7.895327][ T1] ? ioread16+0x2f/0x90
[ 7.895327][ T1] ? __pfx_virtscsi_ctrl_done+0x10/0x10
[ 7.895327][ T1] vp_find_vqs_msix+0x8b2/0xc80
[ 7.895327][ T1] vp_find_vqs+0x4c/0x4e0
[ 7.895327][ T1] virtscsi_init+0x8db/0xd00
[ 7.895327][ T1] ? __pfx_virtscsi_init+0x10/0x10
[ 7.895327][ T1] ? __pfx_default_calc_sets+0x10/0x10
[ 7.895327][ T1] ? scsi_host_alloc+0xa57/0xea0
[ 7.895327][ T1] ? vp_get+0xfd/0x140
[ 7.895327][ T1] virtscsi_probe+0x3ea/0xf60
[ 7.895327][ T1] ? __pfx_virtscsi_probe+0x10/0x10
[ 7.905395][ T1] ? kernfs_add_one+0x156/0x8b0
[ 7.905395][ T1] ? virtio_no_restricted_mem_acc+0x9/0x10
[ 7.905395][ T1] ? virtio_features_ok+0x10c/0x270
[ 7.905395][ T1] virtio_dev_probe+0x991/0xaf0
[ 7.905395][ T1] ? __pfx_virtio_dev_probe+0x10/0x10
[ 7.905395][ T1] really_probe+0x2b8/0xad0
[ 7.905395][ T1] __driver_probe_device+0x1a2/0x390
[ 7.905395][ T1] driver_probe_device+0x50/0x430
[ 7.905395][ T1] __driver_attach+0x45f/0x710
[ 7.915312][ T1] ? __pfx___driver_attach+0x10/0x10
[ 7.915312][ T1] bus_for_each_dev+0x239/0x2b0
[ 7.915312][ T1] ? __pfx___driver_attach+0x10/0x10
[ 7.915312][ T1] ? __pfx_bus_for_each_dev+0x10/0x10
[ 7.915312][ T1] ? do_raw_spin_unlock+0x13c/0x8b0
[ 7.915312][ T1] bus_add_driver+0x347/0x620
[ 7.915312][ T1] driver_register+0x23a/0x320
[ 7.915312][ T1] virtio_scsi_init+0x69/0xe0
[ 7.915312][ T1] ? __pfx_virtio_scsi_init+0x10/0x10
[ 7.915312][ T1] do_one_initcall+0x248/0x880
[ 7.925360][ T1] ? __pfx_virtio_scsi_init+0x10/0x10
[ 7.925360][ T1] ? __pfx_do_one_initcall+0x10/0x10
[ 7.925360][ T1] ? lockdep_hardirqs_on_prepare+0x43d/0x780
[ 7.925360][ T1] ? __pfx_parse_args+0x10/0x10
[ 7.925360][ T1] ? do_initcalls+0x1c/0x80
[ 7.925360][ T1] ? rcu_is_watching+0x15/0xb0
[ 7.925360][ T1] do_initcall_level+0x157/0x210
[ 7.925360][ T1] do_initcalls+0x3f/0x80
[ 7.925360][ T1] kernel_init_freeable+0x435/0x5d0
[ 7.925360][ T1] ? __pfx_kernel_init_freeable+0x10/0x10
[ 7.935268][ T1] ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[ 7.935268][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.935268][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.935268][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.935268][ T1] kernel_init+0x1d/0x2b0
[ 7.935268][ T1] ret_from_fork+0x4b/0x80
[ 7.935268][ T1] ? __pfx_kernel_init+0x10/0x10
[ 7.935268][ T1] ret_from_fork_asm+0x1a/0x30
[ 7.935268][ T1] </TASK>
[ 7.935268][ T1] Kernel Offset: disabled
[ 7.935268][ T1] Rebooting in 86400 seconds..
syzkaller build log:
go env (err=<nil>)
GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/syzkaller/jobs-2/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs-2/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/syzkaller/jobs-2/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3076711685=/tmp/go-build -gno-record-gcc-switches'
git status (err=<nil>)
HEAD detached at c8349e485
nothing to commit, working tree clean
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=c8349e48534ea6d8f01515335d95de8ebf5da8df -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240412-102842'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=c8349e48534ea6d8f01515335d95de8ebf5da8df -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240412-102842'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=c8349e48534ea6d8f01515335d95de8ebf5da8df -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240412-102842'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
-DHOSTGOOS_linux=1 -DGIT_REVISION=\"c8349e48534ea6d8f01515335d95de8ebf5da8df\"
Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=112cfbcd180000
Tested on:
commit: 96fca68c Merge tag 'nfsd-6.9-3' of git://git.kernel.or..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git linus
kernel config: https://syzkaller.appspot.com/x/.config?x=d239903bd07761e5
dashboard link: https://syzkaller.appspot.com/bug?extid=ad1b592fc4483655438b
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=10fd1a3b180000