Re: [PATCH v2 1/4] hwmon: (pmbus/core) increase number of phases and add new mask

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The PMBus core driver iterates over `info->phases[page]` to access the `info->pfunc[phase]` array without verifying that the phase count is within the `PMBUS_PHASES` maximum. If a driver configures `info->phases[page]` to a value larger than `PMBUS_PHASES`, it results in an out-of-bounds array read.
--

commit f0d55dee29cf753f56d794471093af9c4d34634d
Author: Nuno Sá <nuno.sa@analog.com>

hwmon: (pmbus/core) increase number of phases and add new mask

This commit increases the maximum number of phases per page to 16 to support
a new upcoming device. It also adds a new mask for controlling the source
of the output voltage.

> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> index 2cd3216b3cd95..920c1102ab6df 100644
> --- a/drivers/hwmon/pmbus/pmbus.h
> +++ b/drivers/hwmon/pmbus/pmbus.h
[ ... ]
> @@ -386,7 +387,7 @@ enum pmbus_sensor_classes {
>  };
>  
>  #define PMBUS_PAGES	32	/* Per PMBus specification */
> -#define PMBUS_PHASES	10	/* Maximum number of phases per page */
> +#define PMBUS_PHASES	16	/* Maximum number of phases per page */

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for a driver
to configure a phase count larger than the new PMBUS_PHASES limit and
cause an out-of-bounds read?

In drivers/hwmon/pmbus/pmbus_core.c:pmbus_add_sensor_attrs(), the loop
uses the unvalidated info->phases[page] as an upper bound to access the
statically dimensioned info->pfunc array (which is sized to PMBUS_PHASES):

				for (phase = 0; phase < info->phases[page];
				     phase++) {
					if (!(info->pfunc[phase] & attrs->func))
						continue;

If a driver calls pmbus_do_probe() with a pmbus_driver_info struct where
info->phases[page] > PMBUS_PHASES, it could result in reading past the
array bounds.

This might lead to a kernel oops during module probe or the creation of
corrupted sysfs attributes by interpreting adjacent memory as functionality
bitmasks.

Since the core framework explicitly validates info->pages > PMBUS_PAGES to
prevent similar overflows, should a similar bounds check be added for
info->phases against PMBUS_PHASES in the core API?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260911-hwmon-max20826-support-v2-0-5e30cbd97d84@analog.com?part=1