netdev - Re: [syzbot] [mm?] WARNING: locking bug in __set_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAADnVQKkLyJ0cbLet3q3X+X70FPAejcqTxP66d82WTO82c16rw@mail.gmail.com>
Date: Thu, 9 Oct 2025 18:02:17 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: syzbot <syzbot+8259e1d0e3ae8ed0c490@...kaller.appspotmail.com>, 
	Johannes Weiner <hannes@...xchg.org>, Brendan Jackman <jackmanb@...gle.com>, 
	LKML <linux-kernel@...r.kernel.org>, linux-mm <linux-mm@...ck.org>, 
	Michal Hocko <mhocko@...e.com>, Network Development <netdev@...r.kernel.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, syzkaller-bugs <syzkaller-bugs@...glegroups.com>, 
	Vlastimil Babka <vbabka@...e.cz>, ziy@...dia.com, bpf <bpf@...r.kernel.org>
Subject: Re: [syzbot] [mm?] WARNING: locking bug in __set_page_owner (2)

On Thu, Oct 9, 2025 at 5:41 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Thu, 9 Oct 2025 17:26:21 -0700 Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> > On Thu, Oct 9, 2025 at 4:52 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
> > >
> > > On Thu, 09 Oct 2025 09:45:33 -0700 syzbot <syzbot+8259e1d0e3ae8ed0c490@...kaller.appspotmail.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit:    2c95a756e0cf net: pse-pd: tps23881: Fix current measuremen..
> > > > git tree:       net
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16e1852f980000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=5bcbbf19237350b5
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=8259e1d0e3ae8ed0c490
> > > > compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > > >
> > > > Unfortunately, I don't have any reproducer for this issue yet.
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/8272657e4298/disk-2c95a756.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/4e53ba690f28/vmlinux-2c95a756.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/6112d620d6fc/bzImage-2c95a756.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+8259e1d0e3ae8ed0c490@...kaller.appspotmail.com
> > >
> > > At 2c95a756e0cf, page_owner.c hasn't been modified in a couple of years.
> > >
> > > How can add_stack_record_to_list()'s spin_lock_irqsave() be "invalid
> > > wait context"?  In NMI, yes, but the trace doesn't indicate that we're
> > > in an NMI.
> > >
> > > Confused.  I'm suspecting BPF involvement.  Cc'ed for help, please.
> >
> > The attached patch should fix it.
> > There are different options, but this one is the simplest.
>
> Cool, thanks.
>
> > From: Alexei Starovoitov <ast@...nel.org>
> > Subject: mm: don't spin in add_stack_record when gfp flags don't allow
> > Date: Thu, 9 Oct 2025 17:15:13 -0700
> >
> > syzbot was able to find the following path:
> >   add_stack_record_to_list mm/page_owner.c:182 [inline]
> >   inc_stack_record_count mm/page_owner.c:214 [inline]
> >   __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333
> >   set_page_owner include/linux/page_owner.h:32 [inline]
> >   post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851
> >   prep_new_page mm/page_alloc.c:1859 [inline]
> >   get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858
> >   alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554
> >
> > Don't spin in add_stack_record_to_list() when it is called
> > from *_nolock() context.
>
> Seems 6.18 will need this.  Do you think it is needed in earlier kernel
> versions?

Maybe. I need to study the git history of that code to see
whether it's a new path or I simply missed it earlier.