On Sun, May 11, 2025 at 5:16 PM syzbot <syzbot+659fcc0678e5a1193143@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hello, > > syzbot found the following issue on: > > HEAD commit: 707df3375124 Merge tag 'media/v6.15-2' of git://git.kernel.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=16b1b2bc580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=91c351a0f6229e67 > dashboard link: https://syzkaller.appspot.com/bug?extid=659fcc0678e5a1193143 > compiler: Debian clang version 20.1.2 (++20250402124445+58df0ef89dd6-1~exp1~20250402004600.97), Debian LLD 20.1.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-707df337.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/bc3944720ea5/vmlinux-707df337.xz > kernel image: https://storage.googleapis.com/syzbot-assets/7bc2f45ae23f/bzImage-707df337.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+659fcc0678e5a1193143@xxxxxxxxxxxxxxxxxxxxxxxxx > > syz.0.0 uses obsolete (PF_INET,SOCK_PACKET) > ================================================================== > BUG: KASAN: vmalloc-out-of-bounds in vrealloc_noprof+0x396/0x430 mm/vmalloc.c:4093 > Write of size 4064 at addr ffffc9000efa1020 by task syz.0.0/5317 > A while back I sent a fix for kasan handling of vrealloc ([0]), but this issue came back even with my changes in [0]. Can anyone from mm side take a look at vrealloc_noprof() and see if we are missing anything else to convince KASAN that we are using vrealloc() correctly? Seems like kasan_poison_vmalloc() + kasan_unpoison_vmalloc() dance isn't covering all cases? Or am I missing something? It's doubtful that there is any BPF-side bug in using kvrealloc(). [0] https://lore.kernel.org/linux-mm/20241126005206.3457974-1-andrii@xxxxxxxxxx/ > CPU: 0 UID: 0 PID: 5317 Comm: syz.0.0 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full) > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 > Call Trace: > <TASK> > dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 > print_address_description mm/kasan/report.c:408 [inline] > print_report+0xb4/0x290 mm/kasan/report.c:521 > kasan_report+0x118/0x150 mm/kasan/report.c:634 > check_region_inline mm/kasan/generic.c:-1 [inline] > kasan_check_range+0x29a/0x2b0 mm/kasan/generic.c:189 > __asan_memset+0x22/0x50 mm/kasan/shadow.c:84 > vrealloc_noprof+0x396/0x430 mm/vmalloc.c:4093 > push_insn_history+0x184/0x650 kernel/bpf/verifier.c:3874 > do_check+0x597/0xd630 kernel/bpf/verifier.c:19450 > do_check_common+0x168d/0x20b0 kernel/bpf/verifier.c:22776 > do_check_main kernel/bpf/verifier.c:22867 [inline] > bpf_check+0x13679/0x19a70 kernel/bpf/verifier.c:24033 > bpf_prog_load+0x1318/0x1930 kernel/bpf/syscall.c:2971 > __sys_bpf+0x5f1/0x860 kernel/bpf/syscall.c:5834 > __do_sys_bpf kernel/bpf/syscall.c:5941 [inline] > __se_sys_bpf kernel/bpf/syscall.c:5939 [inline] > __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5939 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f649c58e969 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f649d4dd038 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 > RAX: ffffffffffffffda RBX: 00007f649c7b5fa0 RCX: 00007f649c58e969 > RDX: 0000000000000048 RSI: 00002000000017c0 RDI: 0000000000000005 > RBP: 00007f649c610ab1 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 0000000000000000 R14: 00007f649c7b5fa0 R15: 00007fff542287e8 > </TASK> > > The buggy address belongs to the virtual mapping at > [ffffc9000ef81000, ffffc9000efa3000) created by: > kvrealloc_noprof+0x82/0xe0 mm/slub.c:5109 > > The buggy address belongs to the physical page: > page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x3ffd0 pfn:0x3efe5 > flags: 0x4fff00000000000(node=1|zone=1|lastcpupid=0x7ff) > raw: 04fff00000000000 0000000000000000 dead000000000122 0000000000000000 > raw: 000000000003ffd0 0000000000000000 00000001ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > page_owner tracks the page as allocated > page last allocated via order 0, migratetype Unmovable, gfp_mask 0x102cc2(GFP_HIGHUSER|__GFP_NOWARN), pid 5317, tgid 5316 (syz.0.0), ts 82587533383, free_ts 81110216781 > set_page_owner include/linux/page_owner.h:32 [inline] > post_alloc_hook+0x1d8/0x230 mm/page_alloc.c:1718 > prep_new_page mm/page_alloc.c:1726 [inline] > get_page_from_freelist+0x21ce/0x22b0 mm/page_alloc.c:3688 > __alloc_pages_slowpath+0x2fe/0xcc0 mm/page_alloc.c:4509 > __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:4983 > alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2301 > alloc_frozen_pages_noprof mm/mempolicy.c:2372 [inline] > alloc_pages_noprof+0xa9/0x190 mm/mempolicy.c:2392 > vm_area_alloc_pages mm/vmalloc.c:3591 [inline] > __vmalloc_area_node mm/vmalloc.c:3669 [inline] > __vmalloc_node_range_noprof+0x8fe/0x12c0 mm/vmalloc.c:3844 > __kvmalloc_node_noprof+0x3a0/0x5e0 mm/slub.c:5034 > kvrealloc_noprof+0x82/0xe0 mm/slub.c:5109 > push_insn_history+0x184/0x650 kernel/bpf/verifier.c:3874 > do_check+0x597/0xd630 kernel/bpf/verifier.c:19450 > do_check_common+0x168d/0x20b0 kernel/bpf/verifier.c:22776 > do_check_main kernel/bpf/verifier.c:22867 [inline] > bpf_check+0x13679/0x19a70 kernel/bpf/verifier.c:24033 > bpf_prog_load+0x1318/0x1930 kernel/bpf/syscall.c:2971 > __sys_bpf+0x5f1/0x860 kernel/bpf/syscall.c:5834 > __do_sys_bpf kernel/bpf/syscall.c:5941 [inline] > __se_sys_bpf kernel/bpf/syscall.c:5939 [inline] > __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5939 > page last free pid 82 tgid 82 stack trace: > reset_page_owner include/linux/page_owner.h:25 [inline] > free_pages_prepare mm/page_alloc.c:1262 [inline] > free_unref_folios+0xb81/0x14a0 mm/page_alloc.c:2782 > shrink_folio_list+0x3053/0x4e90 mm/vmscan.c:1552 > evict_folios+0x417b/0x5110 mm/vmscan.c:4698 > try_to_shrink_lruvec+0x705/0x990 mm/vmscan.c:4859 > shrink_one+0x21b/0x7c0 mm/vmscan.c:4904 > shrink_many mm/vmscan.c:4967 [inline] > lru_gen_shrink_node mm/vmscan.c:5045 [inline] > shrink_node+0x3139/0x3750 mm/vmscan.c:6016 > kswapd_shrink_node mm/vmscan.c:6867 [inline] > balance_pgdat mm/vmscan.c:7050 [inline] > kswapd+0x1675/0x2970 mm/vmscan.c:7315 > kthread+0x70e/0x8a0 kernel/kthread.c:464 > ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:153 > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 > > Memory state around the buggy address: > ffffc9000efa0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffffc9000efa0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >ffffc9000efa1000: 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ^ > ffffc9000efa1080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ffffc9000efa1100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 > ================================================================== > > > --- > 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@xxxxxxxxxxxxxxxx. > > 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
