From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
syzbot+9cb1ac7fce4944ba9165@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] klist: avoid accesses after waking klist_remove()
Date: Tue, 25 Aug 2026 09:35:29 +0200 [thread overview]
Message-ID: <2026082544-polyester-regroup-d935@gregkh> (raw)
In-Reply-To: <ao051-T1sSobzcXP@gmail.com>
On Tue, Aug 25, 2026 at 09:03:25AM +0200, Karl Mehltretter wrote:
> On Tue, Aug 25, 2026 at 07:25:48AM +0100, Greg Kroah-Hartman wrote:
> > > to go out of scope and its caller to free or reuse the node.
> >
> > But does that ever actually happen?
>
> klist_remove() waits until the node is removed so the containing object can
> be freed. bus_remove_driver() can later free drv->p, while device_move()
> immediately adds the same node to another list.
>
> > > The task reference keeps the waiter task alive if it returns and exits
> > > before wake_up_process(). wake_up_process() provides the full barrier
> > > required by the sleep/wakeup protocol, so remove the explicit mb().
> >
> > I'm confused, what actual bug is here?
>
> I found this during a targeted klist.c review.
>
> Only later I cam across the syzbot report. That report became too prominent
> in the commit message.
>
> klist_release() sets waiter->woken, then reads waiter->process and later
> writes n->n_klist. After seeing woken, the waiter can return on another CPU.
>
> My initial KASAN reproducer was klist-only. One thread held an iterator while
> another removed and freed the object. A delay after the wakeup made
> the race easy, hit KASAN on n_klist in qemu arm64.
Yes, but real-world use causes this in the kernel today?
>
> > > Closes: https://syzkaller.appspot.com/bug?extid=9cb1ac7fce4944ba9165
> > > Tested-by: syzbot+9cb1ac7fce4944ba9165@syzkaller.appspotmail.com
> >
> > Are you sure? the whole bind/unbind mess that syzbot is throwing at us
> > right now is really causing people to go down odd paths in thinking it's
> > even a valid thing to consider at all.
>
> I did not verify the dummy_udc bind/unbind sequence. The klist issue
> does not depend on this USB path.
>
> I can reword a v2 around the generic reproducer. anything else I should
> investigate before sending it ?
Again, what user of this api in the kernel is causing this type of
problem to require these changes?
thanks,
greg k-h
prev parent reply other threads:[~2026-08-25 7:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 4:04 [PATCH] klist: avoid accesses after waking klist_remove() Karl Mehltretter
2026-08-25 5:25 ` Greg Kroah-Hartman
2026-08-25 7:03 ` Karl Mehltretter
2026-08-25 7:35 ` Greg Kroah-Hartman [this message]
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=2026082544-polyester-regroup-d935@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=dakr@kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=kmehltretter@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+9cb1ac7fce4944ba9165@syzkaller.appspotmail.com \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.