Devicetree
 help / color / mirror / Atom feed
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


  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