Re: [PATCH v2] hwmon: add a driver for the temp/voltage sensor on PolarFire SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Ignored `regmap_read()` return values lead to the use of uninitialized stack variables, potentially leaking kernel memory.
- [Medium] Arithmetic overflow in `mpfs_tvs_interval_write` bypasses interval bounds checking.
- [Medium] The driver ignores the return values of hardware write operations, masking errors from the hwmon core and userspace.
- [Medium] Destructive `regmap_write()` to the control register overwrites existing configuration, such as the update interval.
--

commit 3e2d5f8cc5d07efdc63c9af851354b4ce076c3a4
Author: Lars Randers <lranders@mail.dk>
Subject: hwmon: add a driver for the temp/voltage sensor on PolarFire SoC

Add a driver for the temperature and voltage sensors on PolarFire SoC.
The temperature reports how hot the die is, and the voltages are the
SoC's 1.05, 1.8 and 2.5 volt rails respectively.

> diff --git a/drivers/hwmon/tvs-mpfs.c b/drivers/hwmon/tvs-mpfs.c
> new file mode 100644
> index 0000000000000..f086f178b4bab
> --- /dev/null
> +++ b/drivers/hwmon/tvs-mpfs.c

[ ... ]

> +static int mpfs_tvs_voltage_read(struct mpfs_tvs *data, u32 attr,
> +				 int channel, long *val)
> +{
> +	u32 tmp, control;
> +
> +	if (attr != hwmon_in_input && attr != hwmon_in_enable)
> +		return -EOPNOTSUPP;
> +
> +	regmap_read(data->regmap, MPFS_TVS_CTRL, &control);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this code leak uninitialized stack memory if the hardware read fails?

Because the return value of regmap_read() is ignored, control (and tmp
below) could remain uninitialized on a read failure. This uninitialized
data is then used in bitwise operations and potentially returned to
userspace via *val.

The same pattern appears in mpfs_tvs_temp_read() and mpfs_tvs_interval_read().

> +
> +	switch (channel) {
> +	case SENSOR_V2P5:

[ ... ]

> +static int mpfs_tvs_voltage_write(struct mpfs_tvs *data, u32 attr,
> +				  int channel, long val)
> +{
> +	u32 tmp;
> +
> +	if (attr != hwmon_in_enable)
> +		return -EOPNOTSUPP;
> +
> +	switch (channel) {
> +	case SENSOR_V2P5:
> +		if (val > 1 || val < 0)
> +			return -EINVAL;
> +
> +		tmp = FIELD_PREP(MPFS_TVS_CTRL_V2P5_ENABLE, val);
> +		regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> +				   MPFS_TVS_CTRL_V2P5_ENABLE, tmp);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Should this check the return value of regmap_update_bits()?

By unconditionally returning 0 at the end of the function, hardware write 
failures are masked from the hwmon core and userspace.

The same pattern appears in mpfs_tvs_temp_write() and 
mpfs_tvs_interval_write().

> +		break;

[ ... ]

> +static int mpfs_tvs_interval_write(struct mpfs_tvs *data, u32 attr, long val)
> +{
> +	unsigned long temp = val;
> +
> +	if (attr != hwmon_chip_update_interval)
> +		return -EOPNOTSUPP;
> +
> +	temp *= 1000;
        ^^^^^^^^^^^^^

[Severity: Medium]
Could this multiplication overflow before bounds validation occurs?

If a large value is passed (e.g., val = 4294968 on a 32-bit architecture),
temp * 1000 could wrap around to a small value like 480. Divided by 
MPFS_TVS_INTERVAL_SCALE (32), this gives 15, which would successfully pass 
the temp > 254 upper-bound check below and silently write an invalid 
interval to the hardware.

> +	temp /= MPFS_TVS_INTERVAL_SCALE;
> +
> +	/*
> +	 * The value is 8 bits wide, but 255 is described as
> +	 * "255= Do single set of transfers when scoverride set"
> +	 * but there's no scoverride bit in the tvs register region.
> +	 * Ban using 255 since its behaviour is suspect.
> +	 */
> +	if (temp > 254)
> +		return -EINVAL;
> +
> +	temp <<= MPFS_TVS_INTERVAL_OFFSET;
> +	regmap_update_bits(data->regmap, MPFS_TVS_CTRL,
> +			   MPFS_TVS_INTERVAL_MASK, temp);
> +
> +	return 0;
> +}

[ ... ]

> +static int mpfs_tvs_probe(struct platform_device *pdev)
> +{
> +	struct device *hwmon_dev;
> +	struct mpfs_tvs *data;
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->regmap = device_node_to_regmap(pdev->dev.parent->of_node);
> +	if (IS_ERR(data->regmap))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(data->regmap),
> +				     "Failed to find syscon regmap\n");
> +
> +	regmap_write(data->regmap, MPFS_TVS_CTRL, MPFS_TVS_CTRL_ENABLE_ALL);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Does this destructively overwrite existing configuration in the control register?

Because this uses regmap_write() rather than a read-modify-write operation
like regmap_update_bits(), it replaces the entire register contents. This 
clears the INTERVAL bits (15:8) to 0 and zeroes out other status bits, which 
might erase configuration previously set by the bootloader.

> +
> +	hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, "mpfs_tvs",
> +							 data,
> +							 &mpfs_tvs_chip_info,
> +							 NULL);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603-ongoing-brunette-51e35be6d93e@spud?part=1