Message-ID: <CAEf4BzbqrLhB6OmkuqNQMkFQFYzbW1-abUni2vdX0N5mwaQvjA@mail.gmail.com>
Date: Tue, 13 May 2025 09:20:52 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzbot <syzbot+659fcc0678e5a1193143@...kaller.appspotmail.com>, 
	Linux Memory Management List <linux-mm@...ck.org>, andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org, 
	daniel@...earbox.net, eddyz87@...il.com, haoluo@...gle.com, 
	john.fastabend@...il.com, jolsa@...nel.org, kpsingh@...nel.org, 
	linux-kernel@...r.kernel.org, martin.lau@...ux.dev, sdf@...ichev.me, 
	song@...nel.org, syzkaller-bugs@...glegroups.com, yonghong.song@...ux.dev
Subject: Re: [syzbot] [bpf?] KASAN: vmalloc-out-of-bounds Write in
 vrealloc_noprof (2)

On Tue, May 13, 2025 at 1:13 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Tue, 13 May 2025 at 00:52, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> >
> > On Sun, May 11, 2025 at 5:16 PM syzbot
> > <syzbot+659fcc0678e5a1193143@...kaller.appspotmail.com> 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@...kaller.appspotmail.com
> > >
> > > 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@kernel.org/
>
> 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@kernel.org/
> 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.

So that's the case when we realloc to a size that's smaller than
previously alloc'ed vma. So presumably the previous allocation should
have unpoisoned that. But I think you are right, there is a disconnect
between requested size of allocation (which doesn't have to be a
multiple of PAGE_SIZE), and actual page size-aligned VMA size. We
don't seem to keep track of the original requested memory size.

So yes, a simple "fix" would be to temporarily unpoison and memset.
I'll send a patch, don't know if mm/kasan folks would have any better
suggestions. Thanks for suggestion, Dmitry!

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 3ed720a787ec..93b4c1758498 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -4089,8 +4089,11 @@ void *vrealloc_noprof(const void *p, size_t
size, gfp_t flags)
         */
        if (size <= old_size) {
                /* Zero out spare memory. */
-               if (want_init_on_alloc(flags))
+               if (want_init_on_alloc(flags)) {
+                       kasan_unpoison_vmalloc(p + size, old_size - size,
+                                              KASAN_VMALLOC_PROT_NORMAL);
                        memset((void *)p + size, 0, old_size - size);
+               }
                kasan_poison_vmalloc(p + size, old_size - size);
                kasan_unpoison_vmalloc(p, size, KASAN_VMALLOC_PROT_NORMAL);
                return (void *)p;

(note, the diff formatting will be butchered courtesy of gmail, so
don't try to actually apply that)

>
>
> > > 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@...glegroups.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
> >
> > --
> > 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@...glegroups.com.
> > To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/CAEf4BzbsmHonD-G45-Jo8RQHPjDYEz-Nwx0MGtsk427tgsqGkg%40mail.gmail.com.

Powered by blists - more mailing lists