Re: [PATCH AUTOSEL 6.18-5.10] leds: pca9532: Don't stop blinking for non-zero brightness

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Race condition in N2100_BEEP input device teardown leading to use-after-free
--

commit 7c75890ff5fc7d7cfe4c161d927be50be43a1827
Author: Tobias Deiminger <tobias.deiminger@linutronix.de>

leds: pca9532: Don't stop blinking for non-zero brightness

This patch prevents the pca9532 driver from incorrectly stopping hardware
blinking when a non-zero brightness value is set. It adds a guard to return 
early if the LED state is PCA9532_PWM1, aligning the behavior with the 
LED subsystem documentation.

Link: https://patch.msgid.link/20260331202848.658676-1-tobias.deiminger@linutronix.de

> diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
> index 0344189bb991c..dae7c67605084 100644
> --- a/drivers/leds/leds-pca9532.c
> +++ b/drivers/leds/leds-pca9532.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but while looking at this driver,
I noticed a potential use-after-free race during teardown of the N2100_BEEP
input device.

In pca9532_destroy_devices(), the worker is canceled but the managed input
device remains active until devres unwinds:

    case PCA9532_TYPE_N2100_BEEP:
        if (data->idev != NULL) {
            cancel_work_sync(&data->work);
            data->idev = NULL;
        }
        break;

If an input event (e.g., SND_BELL) arrives through the evdev node in this
narrow window before devres unwinds, pca9532_event() will blindly queue
up the work again:

    schedule_work(&data->work);

Once devres unwinding completes, the data structure is freed, but the
newly queued work remains active. When pca9532_input_work() executes, it
could access the freed data:

    static void pca9532_input_work(struct work_struct *work)
    {
        ...
        mutex_lock(&data->update_lock);

Could this result in a use-after-free crash if a user space process writes
to the input event node during driver removal? Should the input device be
explicitly unregistered before canceling the work?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-192-sashal@kernel.org?part=1