Re: [PATCH RFC 19/20] dt-bindings: input: touchscreen: goodix: Add binding for GT970

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Heap out-of-bounds write in init_8952 due to hardcoded sensor initialization without validating num_sensors.
- [High] Missing upper bounds check on num_sensors causes a NULL pointer dereference in tsens_threshold_violated.
--

commit e2c03bc036014af0112367e60c92c407413054c8
Author: Muzaffer Kadir <muzafferkadir@mainlining.org>

dt-bindings: input: touchscreen: goodix: Add binding for GT970

This commit adds a new compatible string for the GT970 touchscreen controller
to the Goodix binding schema. It documents GT970 as falling back to the GT911
compatible string since it works with the GT911 driver.

> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> index a26a54d63a1c0..4be2c137abd7c 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but I noticed a potential heap
out-of-bounds write in init_8952() due to hardcoded sensor initialization
without validating num_sensors.

If a device tree specifies a #qcom,sensors value less than 11 for a
platform using init_8952() (like msm8952), tsens_probe() allocates a priv
structure with a smaller flexible array for sensors.

drivers/thermal/qcom/tsens-v1.c:init_8952() {
    ...
	priv->sensor[10].p1_calib_offset = -3;
	priv->sensor[10].p2_calib_offset = -2;
    ...
}

Does this code overflow the priv->sensor[] array? Because init_8952()
unconditionally assigns values up to priv->sensor[10], this can overwrite
memory past the allocation if a malformed device tree property is provided
by the bootloader.

[Severity: High]
This is a pre-existing issue, but there appears to be a missing upper bounds
check on num_sensors that causes a NULL pointer dereference.

In tsens_probe(), the unbounded value is introduced here:

drivers/thermal/qcom/tsens.c:tsens_probe() {
    ...
	if (np)
		of_property_read_u32(np, "#qcom,sensors", &num_sensors);
    ...
}

If #qcom,sensors specifies a value greater than priv->feat->max_sensors,
tsens_probe() sets priv->num_sensors to this larger value. init_common()
allocates regmap_field entries in priv->rf only up to max_sensors.

Later, tsens_irq_thread() iterates up to priv->num_sensors and calls
tsens_threshold_violated(), which dereferences the uninitialized regmap
field:

drivers/thermal/qcom/tsens.c:tsens_threshold_violated() {
    ...
	ret = regmap_field_read(priv->rf[UPPER_STATUS_0 + hw_id], &d->up_viol);
    ...
}

Does this cause a NULL pointer dereference when accessing priv->rf[]? For
sensors beyond max_sensors, the regmap_field pointer is NULL, causing
regmap_field_read() to crash if a malformed device tree property is
present. Could we validate num_sensors against max_sensors during probe?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260912-msm8952-initial-support-v1-0-0e742578b524@mainlining.org?part=19