Re: [PATCH 3/5] hwmon: (pmbus/core) Add mapping function to pmbus_read_block_data()
Guenter Roeck <[email protected]> Tue, 4 Aug 2026 07:16:51 -0700
| Newsgroups | org.kernel.vger.linux-hwmon,dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <[email protected]> |
On 8/4/26 02:05, Nuno Sá wrote: > On Tue, Jul 28, 2026 at 11:13:26AM -0700, Guenter Roeck wrote: >> On 7/28/26 09:27, [email protected] wrote: >>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: >>> >>> New issues: >>> - [High] Stack buffer overflow in `pmbus_debugfs_block_read` due to unbounded return value from custom `read_block_data` callback. >>> >>> Pre-existing issues: >>> - [High] TOCTOU data race on PMBus hardware page selection during probe. >>> -- >>> >>> --- Patch [3]: [PATCH 3/5] hwmon: (pmbus/core) Add mapping function to pmbus_read_block_data() --- >>> commit c4bd4d03203a9fd14a7a2bcff69ec842b441fa68 >>> Author: Nuno Sá <[email protected]> >>> >>> hwmon: (pmbus/core) Add mapping function to pmbus_read_block_data() >>> >>> This commit introduces a mapping function to pmbus_read_block_data() in >>> preparation for adding support to a device which needs to use its own >>> read_block implementation. >>> >>>> diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h >>>> index 3d5586c67f840..d697939ec8921 100644 >>>> --- a/drivers/hwmon/pmbus/pmbus.h >>>> +++ b/drivers/hwmon/pmbus/pmbus.h >>>> @@ -459,6 +459,9 @@ struct pmbus_driver_info { >>>> int (*read_byte_data)(struct i2c_client *client, int page, int reg); >>>> int (*read_word_data)(struct i2c_client *client, int page, int phase, >>>> int reg); >>>> + /* size of data_buf is I2C_SMBUS_BLOCK_MAX + 2 */ >>>> + int (*read_block_data)(struct i2c_client *client, int page, u8 reg, >>>> + char *data_buf); >>> >>> [Severity: High] >>> Does this API need a size limit parameter? The comment specifies the buffer >>> size is 34, without providing a limit parameter to the callback, which might >>> encourage callbacks to return values up to 34. >>> >> >> The maximum amount of data returned must be 32 bytes, not 34. Callers define >> a larger buffer size to be able to append, for example, '\n\0'. The function >> itself, however, must not return more than 32 bytes of data, plus the data >> length in the first byte. > > Curious, do you want me to drop the comment or your reply is also about > giving AI context so it does not come up again with the comment? > Point was that the comment isn't accurate. The data buffer length must be at least I2C_SMBUS_BLOCK_MAX, not I2C_SMBUS_BLOCK_MAX + 2, and the function must never return more than I2C_SMBUS_BLOCK_MAX bytes of data (and the number of bytes as return value). Having a comment is fine, only it must reflect the actual API. Thanks, Guenter