On Wed, Aug 19, 2026 at 08:32:45PM +0800, Runyu Xiao wrote:

On Tue, Aug 18, 2026 at 20:23:10 +0200, Greg Kroah-Hartman wrote:

...

How was this found and tested?

Found by code inspection: gb_lights_channel_register() publishes the LED class device and its brightness callback before mutex_init(&light->channels[i].lock) runs, so a concurrent brightness update can take an uninitialized mutex.

What tool did this inspection? A LLM?

Tested by reproducing that code shape in a minimal out-of-tree module under QEMU (kernel 6.1.66 with CONFIG_DEBUG_MUTEXES=y and CONFIG_DEBUG_LOCK_ALLOC=y), since the real driver needs greybus/LED hardware I don't have. The module kzalloc's a channel, registers (publishes) it, and runs the brightness callback, which takes the embedded mutex:

• before the fix, mutex_init() runs after register, so the callback locks the still-zeroed mutex and trips

  DEBUG_LOCKS_WARN_ON(lock->magic != lock)
  WARNING: CPU: 1 PID: 188 at kernel/locking/mutex.c:582 __mutex_lock+0x712/0xd20
  
  
  

• after the fix, mutex_init() runs before register and the same trigger path produces no warning.

But that isn't testing anything at all.

And why 6.1.66? That's not what new patches need to be made against, as it's years old.

The real driver hits this as a race (a concurrent brightness update), whereas the reproducer runs the callback synchronously during registration to make it deterministic; both leave the callback observing an uninitialized lock.

What "reproducer"? Again, was this done by a LLM? Where is the "reproducer"?

thanks,

greg k-h