Re: [PATCH] klist: avoid accesses after waking klist_remove()

[Greg Kroah-Hartman]

On Tue, Aug 25, 2026 at 06:04:08AM +0200, Karl Mehltretter wrote:
> klist_release() publishes waiter->woken before its final accesses to the
> stack waiter and node. klist_remove() can then return, allowing the waiter
> to go out of scope and its caller to free or reuse the node.

But does that ever actually happen?

> Clear n_klist and take a task reference before publishing woken. Use
> release/acquire accesses for that publication and wake the referenced task.
> 
> 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?

> Fixes: 8b0c250be489 ("[PATCH] add klist_node_attached() to determine if a node is on a list or not.")
> Fixes: 210272a28465 ("driver core: Remove completion from struct klist_node")
> Reported-by: syzbot+9cb1ac7fce4944ba9165@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=9cb1ac7fce4944ba9165
> Tested-by: syzbot+9cb1ac7fce4944ba9165@xxxxxxxxxxxxxxxxxxxxxxxxx

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.

Is this a "valid" bind path for this driver and hardware?  If it is,
then maybe we should consider this, but if it isn't, then thinking that
klist is where the bug is isn't correct.

I'm going to be submitting a "taint" flag for when bind/unbind is used,
as this all is a debugging aid that has gone rouge...

thanks,

greg k-h