On Tue, 13 May 2025 at 00:52, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > 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/ Hi Andrii, The report flags the very memset that's visible in this patch chunk, right? https://lore.kernel.org/linux-mm/20241126005206.3457974-1-andrii@xxxxxxxxxx/ Unless I am missing something obvious, the unpoison is added _after_ the memset, so it can't help. The unpoison should be done _before_ the memset. > > 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 > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@xxxxxxxxxxxxxxxx. > To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/CAEf4BzbsmHonD-G45-Jo8RQHPjDYEz-Nwx0MGtsk427tgsqGkg%40mail.gmail.com.
