Re: [PATCH v2] Input: rmi4 - Use platform data instead of query, when available

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Potential kernel panic due to division by zero if hardware returns 0 for DPM resolution.
- [High] Read of uninitialized kernel stack memory if a device provides a small `reg_size` but claims presence of multiple subpackets.
--

--- Patch [1]: [PATCH v2] Input: rmi4 - Use platform data instead of query, when available ---
commit abbd3f045bbd60bcd7253a3917acc57dc4a898a0
Author: David Heidelberg <david@ixit.cz>
Subject: Input: rmi4 - Use platform data instead of query, when available

This commit updates the RMI4 F12 driver to respect device-tree provided
touchscreen-x-mm and touchscreen-y-mm values. It prevents overriding
these values with sensor-provided data if they are already defined.

Link: https://patch.msgid.link/20260731-respect-x-y-mm-v1-0-3e85a4bec745@ixit.cz

> diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c
> index 88c28089de993..841884d967a3d 100644
> --- a/drivers/input/rmi4/rmi_f12.c
> +++ b/drivers/input/rmi4/rmi_f12.c
> @@ -155,6 +155,10 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)

[Severity: High]
This is a pre-existing issue, but can this function leak uninitialized kernel
stack memory?

In rmi_f12_read_sensor_tuning(), a buffer is allocated on the stack without
initialization:

    u8 buf[15];

Later, rmi_read_block() populates item->reg_size bytes. If a malicious
peripheral provides a descriptor with a small reg_size but sets multiple bits
in subpacket_map, the function reads past the initialized portion of buf:

    sensor->max_x = get_unaligned_le16(&buf[offset]);

Is it possible to initialize buf to zero to prevent exposing stack contents
when the hardware-provided reg_size is less than the offset required by the
advertised subpackets?

>  		offset += 4;
>  	}
>  
> +	/* When platform data are provided, we're done */
> +	if (sensor->x_mm && sensor->y_mm)
> +		return 0;
> +

[ ... ]

>  		dpm_resolution = buf[0];
>  
> -		sensor->x_mm = sensor->max_x / dpm_resolution;
> -		sensor->y_mm = sensor->max_y / dpm_resolution;
> +		if (!sensor->x_mm)
> +			sensor->x_mm = sensor->max_x / dpm_resolution;

[Severity: High]
This is a pre-existing issue, but could this division cause a kernel panic?

If a misconfigured or malicious hardware peripheral returns 0 when the DPM
resolution query register is read, buf[0] and thus dpm_resolution will be 0.

Does this require a check to ensure dpm_resolution is non-zero before using
it as a divisor?

> +		if (!sensor->y_mm)
> +			sensor->y_mm = sensor->max_y / dpm_resolution;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-respect-x-y-mm-v2-1-e0681ed3d63c@ixit.cz?part=1