Re: [PATCH v2 3/3] Input: synaptics_i2c - return 0 explicitly on success

[email protected] Wed, 29 Jul 2026 17:16:50 +0000
Newsgroups org.kernel.vger.linux-input
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The delayed work `touch->dwork` is not cancelled on driver unbind or probe failure, leading to a use-after-free.
--

--- Patch [3]: [PATCH v2 3/3] Input: synaptics_i2c - return 0 explicitly on success ---
commit 2cc2d0ff5c54be0c06b9f9251e169b1467e86f9b
Author: Sang-Heon Jeon <[email protected]>

Input: synaptics_i2c - return 0 explicitly on success

error is always zero at the last return in synaptics_i2c_reg_set().
Explicitly return 0 on the success path instead of returning error,
which is the preferred way when there are multiple failure points.

> diff --git a/drivers/input/mouse/synaptics_i2c.c b/drivers/input/mouse/synaptics_i2c.c
> index d4cf982f12632..66e833974c6da 100644
> --- a/drivers/input/mouse/synaptics_i2c.c
> +++ b/drivers/input/mouse/synaptics_i2c.c
> @@ -261,7 +261,7 @@ static s32 synaptics_i2c_reg_set(struct i2c_client *client, u16 reg, u8 val)
>  	if (error)
>  		return error;
>  
> -	return error;
> +	return 0;
>  }
>  
>  static s32 synaptics_i2c_word_get(struct i2c_client *client, u16 reg)

[Severity: High]
This is a pre-existing issue, but I noticed that the delayed work touch->dwork
doesn't appear to be cancelled on driver unbind or probe failure.

In synaptics_i2c_probe(), interrupts are enabled and devm_request_irq() is
called before input_register_device(). The IRQ handler can immediately schedule
touch->dwork.

If input_register_device() fails:

drivers/input/mouse/synaptics_i2c.c:synaptics_i2c_probe() {
	...
	error = input_register_device(touch->input);
	if (error) {
		dev_err(dev, "Input device register failed: %d\n", error);
		return error;
	}
	...
}

The probe function returns the error directly. Since devres will automatically
free the IRQ and the touch structure, but the pending work on system_dfl_wq is
never cancelled, could the delayed work run later and access the freed touch
memory?

Furthermore, the driver lacks a remove callback entirely:

drivers/input/mouse/synaptics_i2c.c:
static struct i2c_driver synaptics_i2c_driver = {
	.driver = {
		.name	= DRIVER_NAME,
		.of_match_table = of_match_ptr(synaptics_i2c_of_match),
		.pm	= pm_sleep_ptr(&synaptics_i2c_pm),
	},

	.probe		= synaptics_i2c_probe,
	.id_table	= synaptics_i2c_id_table,
};

If the device is unbound via sysfs, devres will automatically tear down
resources. However, the delayed work is only explicitly cancelled if the input
device is currently open (via synaptics_i2c_close()).

If the device was never opened before it is unbound, does this mean the work
is never cancelled before the memory is freed?

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=3