From: Dmitry Vyukov <dvyukov@google.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: syzbot <syzbot+659fcc0678e5a1193143@syzkaller.appspotmail.com>,
Linux Memory Management List <linux-mm@kvack.org>,
andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org,
daniel@iogearbox.net, eddyz87@gmail.com, haoluo@google.com,
john.fastabend@gmail.com, jolsa@kernel.org, kpsingh@kernel.org,
linux-kernel@vger.kernel.org, martin.lau@linux.dev,
sdf@fomichev.me, song@kernel.org,
syzkaller-bugs@googlegroups.com, yonghong.song@linux.dev
Subject: Re: [syzbot] [bpf?] KASAN: vmalloc-out-of-bounds Write in vrealloc_noprof (2)
Date: Tue, 13 May 2025 10:13:01 +0200 [thread overview]
Message-ID: <CACT4Y+YpBHXXjU6rPBtB7_-5BvxqZUHW8i6YjOa6twoR=2u1aA@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzbsmHonD-G45-Jo8RQHPjDYEz-Nwx0MGtsk427tgsqGkg@mail.gmail.com>
On Tue, 13 May 2025 at 00:52, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Sun, May 11, 2025 at 5:16 PM syzbot
> <syzbot+659fcc0678e5a1193143@syzkaller.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@syzkaller.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.
> > 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@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
>
> --
> 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@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/syzkaller-bugs/CAEf4BzbsmHonD-G45-Jo8RQHPjDYEz-Nwx0MGtsk427tgsqGkg%40mail.gmail.com.
next prev parent reply other threads:[~2025-05-13 8:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <68213ddf.050a0220.f2294.0045.GAE@google.com>
2025-05-12 22:51 ` Andrii Nakryiko
2025-05-13 8:13 ` Dmitry Vyukov [this message]
2025-05-13 16:20 ` Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACT4Y+YpBHXXjU6rPBtB7_-5BvxqZUHW8i6YjOa6twoR=2u1aA@mail.gmail.com' \
--to=dvyukov@google.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=syzbot+659fcc0678e5a1193143@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox