[syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

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: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

==================================================================
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 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 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

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

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: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

==================================================================
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.

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Hillf Danton]

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;
--

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

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

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Hillf Danton]

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)
--

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

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.

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Vishal Moola]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

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

[-- Attachment #2: 0001-hugetlb-Check-for-anon_vma-prior-to-folio-allocation.patch --]
[-- Type: text/plain, Size: 1797 bytes --]

From fb3415a90a2b2a6fdbe4a5f32370f06141591011 Mon Sep 17 00:00:00 2001
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Date: Mon, 15 Apr 2024 14:17:47 -0700
Subject: [PATCH] hugetlb: Check for anon_vma prior to folio allocation

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.

Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()")
Reported-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
---
 mm/hugetlb.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f826dc681081..fbd278a2e9f6 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6271,6 +6271,10 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 							VM_UFFD_MISSING);
 		}
 
+		ret = vmf_anon_prepare(vmf);
+		if (unlikely(ret))
+			goto out;
+
 		folio = alloc_hugetlb_folio(vma, vmf->address, 0);
 		if (IS_ERR(folio)) {
 			/*
@@ -6310,15 +6314,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 				restore_reserve_on_error(h, vma, vmf->address,
 							folio);
 				folio_put(folio);
+				ret = VM_FAULT_SIGBUS;
 				goto out;
 			}
 			new_pagecache_folio = true;
 		} else {
 			folio_lock(folio);
-
-			ret = vmf_anon_prepare(vmf);
-			if (unlikely(ret))
-				goto backout_unlocked;
 			anon_rmap = 1;
 		}
 	} else {
-- 
2.43.0

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Matthew Wilcox]

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.

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Vishal Moola]

On Mon, Apr 15, 2024 at 3:15 PM Matthew Wilcox <willy@infradead.org> 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.

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Matthew Wilcox]

On Mon, Apr 15, 2024 at 04:02:48PM -0700, Vishal Moola wrote:
> On Mon, Apr 15, 2024 at 3:15 PM Matthew Wilcox <willy@infradead.org> 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?

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Oscar Salvador]

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 <mel@csn.ul.ie>
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

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

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.

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Oscar Salvador]

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

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Andrew Morton]

On Tue, 16 Apr 2024 10:13:31 +0200 Oscar Salvador <osalvador@suse.de> 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?

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Vishal Moola]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

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: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
linus

[-- Attachment #2: 0001-hugetlb-Check-for-anon_vma-prior-to-folio-allocation.patch --]
[-- Type: text/plain, Size: 1863 bytes --]

From 8973cb789bbf64c35ca898541acf3aa6ee8ea2a4 Mon Sep 17 00:00:00 2001
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Date: Mon, 15 Apr 2024 14:17:47 -0700
Subject: [PATCH] hugetlb: Check for anon_vma prior to folio allocation

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.

Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()")
CC: stable@vger.kernel.org
Reported-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
---
 mm/hugetlb.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 23ef240ba48a..948d197cd88f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6274,6 +6274,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 							VM_UFFD_MISSING);
 		}
 
+		if (!(vma->vm_flags & VM_MAYSHARE)) {
+			ret = vmf_anon_prepare(vmf);
+			if (unlikely(ret))
+				goto out;
+		}
+
 		folio = alloc_hugetlb_folio(vma, haddr, 0);
 		if (IS_ERR(folio)) {
 			/*
@@ -6310,15 +6316,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 				 */
 				restore_reserve_on_error(h, vma, haddr, folio);
 				folio_put(folio);
+				ret = VM_FAULT_SIGBUS;
 				goto out;
 			}
 			new_pagecache_folio = true;
 		} else {
 			folio_lock(folio);
-
-			ret = vmf_anon_prepare(vmf);
-			if (unlikely(ret))
-				goto backout_unlocked;
 			anon_rmap = 1;
 		}
 	} else {
-- 
2.43.0

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

> 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: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
>
> #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

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[Vishal Moola]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

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: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git linus

[-- Attachment #2: 0001-hugetlb-Check-for-anon_vma-prior-to-folio-allocation.patch --]
[-- Type: text/plain, Size: 1863 bytes --]

From 8973cb789bbf64c35ca898541acf3aa6ee8ea2a4 Mon Sep 17 00:00:00 2001
From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Date: Mon, 15 Apr 2024 14:17:47 -0700
Subject: [PATCH] hugetlb: Check for anon_vma prior to folio allocation

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.

Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()")
CC: stable@vger.kernel.org
Reported-by: syzbot+ad1b592fc4483655438b@syzkaller.appspotmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
---
 mm/hugetlb.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 23ef240ba48a..948d197cd88f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6274,6 +6274,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 							VM_UFFD_MISSING);
 		}
 
+		if (!(vma->vm_flags & VM_MAYSHARE)) {
+			ret = vmf_anon_prepare(vmf);
+			if (unlikely(ret))
+				goto out;
+		}
+
 		folio = alloc_hugetlb_folio(vma, haddr, 0);
 		if (IS_ERR(folio)) {
 			/*
@@ -6310,15 +6316,12 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
 				 */
 				restore_reserve_on_error(h, vma, haddr, folio);
 				folio_put(folio);
+				ret = VM_FAULT_SIGBUS;
 				goto out;
 			}
 			new_pagecache_folio = true;
 		} else {
 			folio_lock(folio);
-
-			ret = vmf_anon_prepare(vmf);
-			if (unlikely(ret))
-				goto backout_unlocked;
 			anon_rmap = 1;
 		}
 	} else {
-- 
2.43.0

Re: [syzbot] [mm?] KASAN: slab-use-after-free Read in __vma_reservation_common

[syzbot]

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