Re: [PATCH] Input: cyapa: fix runtime PM refcount leak in cyapa_update_rt_suspend_scanrate()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] System suspend and resume callbacks unconditionally dereference `cyapa->input->mutex`, leading to a kernel crash if the device is bound but not operational.
- [High] Explicitly unregistering a `devm`-managed input device during firmware updates leads to devres leaks and use-after-free on driver unbind.
- [High] The driver calls the core helper `input_device_enabled()` without holding `input_dev->mutex`, violating core locking rules.
--

commit fd1e73fff3322eda5030f5978379f809f689c870
Author: Wentao Liang <vulab@iscas.ac.cn>

Input: cyapa: fix runtime PM refcount leak in cyapa_update_rt_suspend_scanrate()

The commit fixes a runtime PM reference leak in
cyapa_update_rt_suspend_scanrate(). It adds a missing
pm_runtime_put_sync_autosuspend() call on the error path when
mutex_lock_interruptible() fails.

Cc: stable@vger.kernel.org
Fixes: 672865080a8f ("Input: cyapa - add runtime power management support")

> diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> index 47000c30e4d8b..c1c23fcf494a9 100644
> --- a/drivers/input/mouse/cyapa.c
> +++ b/drivers/input/mouse/cyapa.c
> @@ -901,8 +901,10 @@ static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
>  	pm_runtime_get_sync(dev);
>  
>  	error = mutex_lock_interruptible(&cyapa->state_sync_lock);
> -	if (error)
> +	if (error) {
> +		pm_runtime_put_sync_autosuspend(dev);
>  		return error;
> +	}
>  
>  	cyapa->runtime_suspend_sleep_time = min_t(u16, time, 1000);
>  	cyapa->runtime_suspend_power_mode =

[Severity: High]
This isn't a bug introduced by this patch, but looking at cyapa_suspend() and
cyapa_resume(), they unconditionally acquire the input device mutex:

drivers/input/mouse/cyapa.c:cyapa_suspend() {
    ...
    error = mutex_lock_interruptible(&cyapa->input->mutex);
    ...
}

drivers/input/mouse/cyapa.c:cyapa_resume() {
    ...
    mutex_lock(&cyapa->input->mutex);
    ...
}

Could this lead to a kernel crash if the trackpad is not operational during
probe (e.g., stuck in bootloader mode) or during a firmware update?

In this scenario, cyapa_create_input_dev() is skipped and cyapa->input remains
NULL. Since cyapa_probe() still returns 0, the device is successfully bound
and the suspend/resume callbacks will dereference the NULL cyapa->input pointer.

[Severity: High]
This is a pre-existing issue, but does cyapa_update_fw_store() leak devres
memory and cause a use-after-free on driver unbind?

cyapa_create_input_dev() allocates the input device using a devm wrapper:

    input = devm_input_allocate_device(dev);

This automatically queues a devres action to unregister the device upon driver
unbind. However, cyapa_update_fw_store() explicitly calls:

    input_unregister_device(cyapa->input);

This unregisters and frees the device, but the devres action attached to the
parent device is not cancelled.

When the driver is eventually unbound, will the devres framework attempt to
execute input_unregister_device() on the already-freed cyapa->input pointer?

[Severity: High]
This is a pre-existing issue, but does cyapa_enable_irq_for_cmd() call
input_device_enabled() without holding the input device mutex?

drivers/input/mouse/cyapa.c:cyapa_enable_irq_for_cmd() {
    ...
    if (!input || !input_device_enabled(input)) {
    ...
}

The input subsystem requires input_device_enabled() to be called while holding
input_dev->mutex. This function is invoked from multiple sysfs attribute
handlers, such as cyapa_calibrate_store(), while only holding the driver's
internal state_sync_lock.

Could this cause a lockdep splat upon sysfs interaction?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609004617.175476-1-vulab@iscas.ac.cn?part=1