From: Guenter Roeck <linux@roeck-us.net>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: sashiko-reviews@lists.linux.dev, "Nuno Sá" <nuno.sa@analog.com>,
conor+dt@kernel.org, linux-hwmon@vger.kernel.org,
devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH 3/5] hwmon: (pmbus/core) Add mapping function to pmbus_read_block_data()
Date: Tue, 4 Aug 2026 07:16:51 -0700 [thread overview]
Message-ID: <58dfd8a9-1502-46d7-a32e-d7b9b9c1ce81@roeck-us.net> (raw)
In-Reply-To: <anGrNyrEX5GX9lYJ@nsa>
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, sashiko-bot@kernel.org 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á <nuno.sa@analog.com>
>>>
>>> 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
next prev parent reply other threads:[~2026-08-04 14:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 16:03 [PATCH 0/5] hwmon: (pmbus) Add support for MAX20826 and similar devices Nuno Sá via B4 Relay
2026-07-28 16:03 ` [PATCH 1/5] hwmon: (pmbus/core) fix regulator enable/disable Nuno Sá via B4 Relay
2026-07-28 16:22 ` sashiko-bot
2026-07-28 16:58 ` Guenter Roeck
2026-07-28 16:03 ` [PATCH 2/5] hwmon: (pmbus/core) increase number of phases and add new mask Nuno Sá via B4 Relay
2026-07-28 16:19 ` sashiko-bot
2026-07-28 16:03 ` [PATCH 3/5] hwmon: (pmbus/core) Add mapping function to pmbus_read_block_data() Nuno Sá via B4 Relay
2026-07-28 16:27 ` sashiko-bot
2026-07-28 18:13 ` Guenter Roeck
2026-08-04 9:05 ` Nuno Sá
2026-08-04 14:16 ` Guenter Roeck [this message]
2026-07-28 21:05 ` Guenter Roeck
2026-07-30 14:27 ` Nuno Sá
2026-07-30 14:47 ` Guenter Roeck
2026-07-30 15:19 ` Nuno Sá
2026-07-30 15:54 ` Guenter Roeck
2026-07-31 15:42 ` Nuno Sá
2026-07-31 16:46 ` Guenter Roeck
2026-08-03 15:03 ` Nuno Sá
2026-08-03 15:45 ` Guenter Roeck
2026-07-28 16:03 ` [PATCH 4/5] dt-bindings: hwmon/pmbus: Document MAX20826 and similar devices Nuno Sá via B4 Relay
2026-07-28 16:17 ` sashiko-bot
2026-07-28 16:03 ` [PATCH 5/5] hwmon: (pmbus) add support for " Nuno Sá via B4 Relay
2026-07-28 16:24 ` sashiko-bot
2026-07-28 22:12 ` Guenter Roeck
2026-08-04 9:20 ` Nuno Sá
2026-07-29 12:18 ` Uwe Kleine-König
2026-07-30 11:08 ` Nuno Sá
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58dfd8a9-1502-46d7-a32e-d7b9b9c1ce81@roeck-us.net \
--to=linux@roeck-us.net \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox