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 <[email protected]> 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-0e742578b...@mainlining.org?part=19
