Re: [PATCH v2] Input: elan_i2c - prevent division by zero on invalid device parameters

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Setting `width_x` and `width_y` to 1 as a fallback introduces a severe arithmetic underflow when calculating touch area sizes.
--

commit 592cc1df694c917c489ca1a6dcea8bd8b7a8d985
Author: Ranjan Kumar <kumarranja@chromium.org>

Input: elan_i2c - prevent division by zero on invalid device parameters

The Elan I2C touchpad driver queries the device for its physical dimensions
and trace counts to calculate the device resolution and width. If the device
provides invalid zero values, this commit adds checks to fall back to safe
default values of 1 to bypass the division and prevent a kernel panic.

> diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
> index fee1796da3d08..32b2849ab36a7 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -425,8 +425,17 @@ static int elan_query_device_parameters(struct elan_tp_data *data)
>  		if (error)
>  			return error;
>  	}
> -	data->width_x = data->max_x / x_traces;
> -	data->width_y = data->max_y / y_traces;
> +
> +	if (unlikely(x_traces == 0 || y_traces == 0)) {
> +		dev_warn(&client->dev,
> +			 "invalid trace numbers: x=%u, y=%u\n",
> +			 x_traces, y_traces);
> +		data->width_x = 1;
> +		data->width_y = 1;

Does setting these fallback values to 1 introduce an arithmetic underflow
regression when calculating touch area sizes?

In elan_report_absolute() and elan_report_contact(), the touch area sizes are
calculated using an expression like:

    area_x = mk_x * (data->width_x - ETP_FWIDTH_REDUCE);

Since ETP_FWIDTH_REDUCE is 90 and data->width_x is an unsigned int, setting
the width to 1 causes the subtraction to underflow, resulting in a massive
unsigned integer.

When passed to input_report_abs(), this value is cast back to a negative
number, violating the 0 minimum boundary configured for ABS_MT_TOUCH_MAJOR.

Could this confuse userspace input handlers and trigger unwanted behaviors?

To prevent this underflow while maintaining the firmware update fallback path,
should the fallback value be at least ETP_FWIDTH_REDUCE (90) instead of 1?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515065235.1913403-1-kumarranja@chromium.org?part=1