Re: PMBus memory overflow

Re: PMBus memory overflow

[Guenter Roeck]

On 4/19/25 19:29, Matt Corallo wrote:
> 
> 
> On 4/19/25 6:49 PM, Guenter Roeck wrote:
>> On 4/19/25 15:38, Guenter Roeck wrote:
>>> On 4/19/25 12:29, Matt Corallo wrote:
>>>
>>>> Hmm, doesn't seem to trigger it at least with pmbus_peek.c, the following diff still doesn't hit the too big prints:
>>>>
>>>
>>> Only idea I have at this point is to either enable smbus tracing in the kernel
>>> or (better) to add test code into i2c_smbus_read_block_data() to see what
>>> exactly triggers the problem.
>>>
>>
>> You could try this:
>>
>> diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
>> index e73afbefe222..b2856f88431d 100644
>> --- a/drivers/i2c/i2c-core-smbus.c
>> +++ b/drivers/i2c/i2c-core-smbus.c
>> @@ -233,6 +233,9 @@ s32 i2c_smbus_read_block_data(const struct i2c_client *client, u8 command,
>>          if (status)
>>                  return status;
>>
>> +       if (data.block[0] > I2C_SMBUS_BLOCK_MAX)
>> +               return -E2BIG;
>> +
>>          memcpy(values, &data.block[1], data.block[0]);
>>          return data.block[0];
>>
>> and maybe temporarily dump the entire buffer if that is seen.
>>
>> diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
>> index e73afbefe222..3dcb8b6b2427 100644
>> --- a/drivers/i2c/i2c-core-smbus.c
>> +++ b/drivers/i2c/i2c-core-smbus.c
>> @@ -233,6 +233,12 @@ s32 i2c_smbus_read_block_data(const struct i2c_client *client, u8 command,
>>          if (status)
>>                  return status;
>>
>> +       if (data.block[0] > I2C_SMBUS_BLOCK_MAX) {
>> +               print_hex_dump_bytes("Bad SMBus block data: ", DUMP_PREFIX_NONE,
>> +                                    data.block, I2C_SMBUS_BLOCK_MAX);
>> +               return -E2BIG;
>> +       }
>> +
>>          memcpy(values, &data.block[1], data.block[0]);
>>          return data.block[0];
>>   }
>>
>> If that doesn't trigger I am going to be really puzzled.
> 
> With this patch the device works fine. With debug enabled I see:
> 
> [  273.730583] i2c-core: driver [pmbus] registered
> [  276.585423] pmbus 1-0058: probe
> [  278.925878] Bad SMBus block data: ff ff b8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> [  278.925881] Bad SMBus block data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> [  278.937859] Bad SMBus block data: ff ff da ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> [  278.937861] Bad SMBus block data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
> [  280.353885] i2c i2c-1: client [pmbus] registered with bus id 1-0058
> [  280.353888] i2c i2c-1: new_device: Instantiated device pmbus at 0x58

Great, thanks for confirming. So the two problems are:

- The cp2112 driver does not validate the first data byte (the length field) when
   receiving SMBus block data from connected devices.
- The I2C (SMBus) core does not validate the first data byte before copying
   the data buffer.

Copying the I2C subsystem mailing list and the I2C maintainer.

Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
I do wonder if a check such as the one above would be appropriate as well, possibly
even combined with a WARN_ONCE().

Thanks,
Guenter

> matt@psu-kern:~$ sensors
> pmbus-i2c-1-58
> Adapter: CP2112 SMBus Bridge on hidraw1
> vin:         123.00 V  (crit min =  -0.50 V, min =  -0.50 V)  ALARM (MIN)
>                         (max =  -0.50 V, crit max =  -0.50 V)
> vcap:        -500.00 mV
> vout1:        12.05 V  (crit min = +128.00 V, min = +128.00 V)
>                         (max = +128.00 V, crit max = +128.00 V)
> fan1:        5304 RPM
> fan2:          -1 RPM
> fan3:           FAULT  ALARM
> fan4:           FAULT  ALARM
> temp1:        +27.0°C  (low  =  -0.5°C, high =  -0.5°C)
>                         (crit low =  -0.5°C, crit =  -0.5°C)
> temp2:        +32.0°C  (low  =  -0.5°C, high =  -0.5°C)
>                         (crit low =  -0.5°C, crit =  -0.5°C)
> temp3:         -0.5°C  (low  =  -0.5°C, high =  -0.5°C)
>                         (crit low =  -0.5°C, crit =  -0.5°C)
> pin:         102.00 W  (max =   1.60 kW)
> pout1:        88.00 W  (max =   0.00 W, crit = -500.00 mW)
>                         (cap = -500.00 mW)
> iin:         988.00 mA (max =  -0.01 A, crit max =  -0.50 A)
> iout1:         7.39 A  (crit min =  -0.50 A, max =  -0.50 A)
>                         (crit max =  -0.50 A)

Re: PMBus memory overflow

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]


> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
> I do wonder if a check such as the one above would be appropriate as well, possibly
> even combined with a WARN_ONCE().

How annoying, there was still an unchecked case left? Sorry. Yes, the
core can have a check for a short-term solution. The long-term solution
is to support SMBUS3.x which allows for 255 byte transfers.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: PMBus memory overflow

[Matt Corallo]

On 4/25/25 4:16 AM, Wolfram Sang wrote:
> 
>> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
>> I do wonder if a check such as the one above would be appropriate as well, possibly
>> even combined with a WARN_ONCE().
> 
> How annoying, there was still an unchecked case left? Sorry. Yes, the
> core can have a check for a short-term solution. The long-term solution
> is to support SMBUS3.x which allows for 255 byte transfers.

Thanks!

Any update here? I guess we already have a patch so no use in me trying to write one. Would be nice 
to get this in a pull so it can head through backports.

Thanks,
Matt

Re: PMBus memory overflow

[Guenter Roeck]

On 5/5/25 13:41, Matt Corallo wrote:
> 
> 
> On 4/25/25 4:16 AM, Wolfram Sang wrote:
>>
>>> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
>>> I do wonder if a check such as the one above would be appropriate as well, possibly
>>> even combined with a WARN_ONCE().
>>
>> How annoying, there was still an unchecked case left? Sorry. Yes, the
>> core can have a check for a short-term solution. The long-term solution
>> is to support SMBUS3.x which allows for 255 byte transfers.
> 
> Thanks!
> 
> Any update here? I guess we already have a patch so no use in me trying to write one. Would be nice to get this in a pull so it can head through backports.
> 

Not from my side, sorry. I am deeply buried in work and don't have time for anything
that isn't super-urgent :-(

Guenter

Re: PMBus memory overflow

[Matt Corallo]

On 5/5/25 4:50 PM, Guenter Roeck wrote:
> On 5/5/25 13:41, Matt Corallo wrote:
>>
>>
>> On 4/25/25 4:16 AM, Wolfram Sang wrote:
>>>
>>>> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
>>>> I do wonder if a check such as the one above would be appropriate as well, possibly
>>>> even combined with a WARN_ONCE().
>>>
>>> How annoying, there was still an unchecked case left? Sorry. Yes, the
>>> core can have a check for a short-term solution. The long-term solution
>>> is to support SMBUS3.x which allows for 255 byte transfers.
>>
>> Thanks!
>>
>> Any update here? I guess we already have a patch so no use in me trying to write one. Would be 
>> nice to get this in a pull so it can head through backports.
>>
> 
> Not from my side, sorry. I am deeply buried in work and don't have time for anything
> that isn't super-urgent :-(

Mmm, shame, its kinda annoying to leave a buffer overflow reachable from a malicious USB device 
sitting around (okay, with the default hardening configs it gets caught, but still). Can we just 
land the above patch from Wolfram to check the length before writing the buffer? Happy to clean it 
up as a formal patch submission if its easier for you.

Thanks,
Matt

Re: PMBus memory overflow

[Guenter Roeck]

On 5/5/25 13:57, Matt Corallo wrote:
> 
> 
> On 5/5/25 4:50 PM, Guenter Roeck wrote:
>> On 5/5/25 13:41, Matt Corallo wrote:
>>>
>>>
>>> On 4/25/25 4:16 AM, Wolfram Sang wrote:
>>>>
>>>>> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
>>>>> I do wonder if a check such as the one above would be appropriate as well, possibly
>>>>> even combined with a WARN_ONCE().
>>>>
>>>> How annoying, there was still an unchecked case left? Sorry. Yes, the
>>>> core can have a check for a short-term solution. The long-term solution
>>>> is to support SMBUS3.x which allows for 255 byte transfers.
>>>
>>> Thanks!
>>>
>>> Any update here? I guess we already have a patch so no use in me trying to write one. Would be nice to get this in a pull so it can head through backports.
>>>
>>
>> Not from my side, sorry. I am deeply buried in work and don't have time for anything
>> that isn't super-urgent :-(
> 
> Mmm, shame, its kinda annoying to leave a buffer overflow reachable from a malicious USB device sitting around (okay, with the default hardening configs it gets caught, but still). Can we just land the above patch from Wolfram to check the length before writing the buffer? Happy to clean it up as a formal patch submission if its easier for you.
> 

Please go ahead.

Thanks,
Guenter

Re: PMBus memory overflow

[Matt Corallo]

Adding security@kernel.org cause probably they should make sure this gets fixed.

On 5/5/25 9:39 PM, Guenter Roeck wrote:
> On 5/5/25 13:57, Matt Corallo wrote:
>>
>>
>> On 5/5/25 4:50 PM, Guenter Roeck wrote:
>>> On 5/5/25 13:41, Matt Corallo wrote:
>>>>
>>>>
>>>> On 4/25/25 4:16 AM, Wolfram Sang wrote:
>>>>>
>>>>>> Wolfram, what do you suggest ? Fixing the cp2112 driver is obviously necessary, but
>>>>>> I do wonder if a check such as the one above would be appropriate as well, possibly
>>>>>> even combined with a WARN_ONCE().
>>>>>
>>>>> How annoying, there was still an unchecked case left? Sorry. Yes, the
>>>>> core can have a check for a short-term solution. The long-term solution
>>>>> is to support SMBUS3.x which allows for 255 byte transfers.
>>>>
>>>> Thanks!
>>>>
>>>> Any update here? I guess we already have a patch so no use in me trying to write one. Would be 
>>>> nice to get this in a pull so it can head through backports.
>>>>
>>>
>>> Not from my side, sorry. I am deeply buried in work and don't have time for anything
>>> that isn't super-urgent :-(
>>
>> Mmm, shame, its kinda annoying to leave a buffer overflow reachable from a malicious USB device 
>> sitting around (okay, with the default hardening configs it gets caught, but still). Can we just 
>> land the above patch from Wolfram to check the length before writing the buffer? Happy to clean it 
>> up as a formal patch submission if its easier for you.
>>
> 
> Please go ahead.
> 
> Thanks,
> Guenter
> 

Re: PMBus memory overflow

[Greg KH]

On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
> Adding security@kernel.org cause probably they should make sure this gets fixed.

That's not how security@k.o works, sorry.  As this is already public, no
need for security@k.o to get involved at all, the normal development
process happens here now.

So, submit a patch and people will be glad to review it!

thanks,

greg k-h

Re: PMBus memory overflow

[Matt Corallo]

On 6/7/25 4:19 AM, Greg KH wrote:
> On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
>> Adding security@kernel.org cause probably they should make sure this gets fixed.
> 
> That's not how security@k.o works, sorry.  As this is already public, no
> need for security@k.o to get involved at all, the normal development
> process happens here now.
> 
> So, submit a patch and people will be glad to review it!

Thanks, figured I'd ask. Sadly there is a patch that folks seem to be okay with to fix a buffer 
overflow but its just sitting.

Matt

Re: PMBus memory overflow

[Greg KH]

On Sat, Jun 07, 2025 at 09:25:44AM -0400, Matt Corallo wrote:
> 
> 
> On 6/7/25 4:19 AM, Greg KH wrote:
> > On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
> > > Adding security@kernel.org cause probably they should make sure this gets fixed.
> > 
> > That's not how security@k.o works, sorry.  As this is already public, no
> > need for security@k.o to get involved at all, the normal development
> > process happens here now.
> > 
> > So, submit a patch and people will be glad to review it!
> 
> Thanks, figured I'd ask. Sadly there is a patch that folks seem to be okay
> with to fix a buffer overflow but its just sitting.

Have a pointer to that patch on lore for the maintainers involved to
review?  Note, we are in the middle of the merge window, so no new
changes can be added to our trees until -rc1 is out.

thanks,

greg k-h

Re: PMBus memory overflow

[Matt Corallo]

On 6/8/25 3:14 AM, Greg KH wrote:
> On Sat, Jun 07, 2025 at 09:25:44AM -0400, Matt Corallo wrote:
>>
>>
>> On 6/7/25 4:19 AM, Greg KH wrote:
>>> On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
>>>> Adding security@kernel.org cause probably they should make sure this gets fixed.
>>>
>>> That's not how security@k.o works, sorry.  As this is already public, no
>>> need for security@k.o to get involved at all, the normal development
>>> process happens here now.
>>>
>>> So, submit a patch and people will be glad to review it!
>>
>> Thanks, figured I'd ask. Sadly there is a patch that folks seem to be okay
>> with to fix a buffer overflow but its just sitting.
> 
> Have a pointer to that patch on lore for the maintainers involved to
> review?  Note, we are in the middle of the merge window, so no new
> changes can be added to our trees until -rc1 is out.

A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, 
at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram 
suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ 
but that's the last he chimed in on this issue.

Matt

Re: PMBus memory overflow

[Matt Corallo]

On 6/9/25 9:57 AM, Matt Corallo wrote:
> 
> 
> On 6/8/25 3:14 AM, Greg KH wrote:
>> On Sat, Jun 07, 2025 at 09:25:44AM -0400, Matt Corallo wrote:
>>>
>>>
>>> On 6/7/25 4:19 AM, Greg KH wrote:
>>>> On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
>>>>> Adding security@kernel.org cause probably they should make sure this gets fixed.
>>>>
>>>> That's not how security@k.o works, sorry.  As this is already public, no
>>>> need for security@k.o to get involved at all, the normal development
>>>> process happens here now.
>>>>
>>>> So, submit a patch and people will be glad to review it!
>>>
>>> Thanks, figured I'd ask. Sadly there is a patch that folks seem to be okay
>>> with to fix a buffer overflow but its just sitting.
>>
>> Have a pointer to that patch on lore for the maintainers involved to
>> review?  Note, we are in the middle of the merge window, so no new
>> changes can be added to our trees until -rc1 is out.
> 
> A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, 
> at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram 
> suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ 
> but that's the last he chimed in on this issue.

Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on 
at least 6.18.

Matt

Re: PMBus memory overflow

[Kees Cook]

On March 1, 2026 5:46:33 AM PST, Matt Corallo <yalbrymrb@mattcorallo.com> wrote:
>
>
>On 6/9/25 9:57 AM, Matt Corallo wrote:
>> 
>> 
>> On 6/8/25 3:14 AM, Greg KH wrote:
>>> On Sat, Jun 07, 2025 at 09:25:44AM -0400, Matt Corallo wrote:
>>>> 
>>>> 
>>>> On 6/7/25 4:19 AM, Greg KH wrote:
>>>>> On Fri, Jun 06, 2025 at 04:57:37PM -0400, Matt Corallo wrote:
>>>>>> Adding security@kernel.org cause probably they should make sure this gets fixed.
>>>>> 
>>>>> That's not how security@k.o works, sorry.  As this is already public, no
>>>>> need for security@k.o to get involved at all, the normal development
>>>>> process happens here now.
>>>>> 
>>>>> So, submit a patch and people will be glad to review it!
>>>> 
>>>> Thanks, figured I'd ask. Sadly there is a patch that folks seem to be okay
>>>> with to fix a buffer overflow but its just sitting.
>>> 
>>> Have a pointer to that patch on lore for the maintainers involved to
>>> review?  Note, we are in the middle of the merge window, so no new
>>> changes can be added to our trees until -rc1 is out.
>> 
>> A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ but that's the last he chimed in on this issue.
>
>Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on at least 6.18.

Looking at the code, I think probably the best place to check would be in i2c_smbus_read_block_data() when it does a I2C_SMBUS_BLOCK_DATA cmd, since the callers are all already checking the returned status.

-- 
Kees Cook

Re: PMBus memory overflow

[Matt Corallo]

On 3/1/26 11:12 AM, Kees Cook wrote:
> 
> 
> On March 1, 2026 5:46:33 AM PST, Matt Corallo <yalbrymrb@mattcorallo.com> wrote:
>>
>>
>> On 6/9/25 9:57 AM, Matt Corallo wrote:
>>>
>>>
>>> On 6/8/25 3:14 AM, Greg KH wrote:
>>>> Have a pointer to that patch on lore for the maintainers involved to
>>>> review?  Note, we are in the middle of the merge window, so no new
>>>> changes can be added to our trees until -rc1 is out.
>>>
>>> A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ but that's the last he chimed in on this issue.
>>
>> Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on at least 6.18.
> 
> Looking at the code, I think probably the best place to check would be in i2c_smbus_read_block_data() when it does a I2C_SMBUS_BLOCK_DATA cmd, since the callers are all already checking the returned status.

I believe that's what the above patch does?

Matt

Re: PMBus memory overflow

[Guenter Roeck]

On 3/1/26 09:10, Matt Corallo wrote:
> 
> 
> On 3/1/26 11:12 AM, Kees Cook wrote:
>>
>>
>> On March 1, 2026 5:46:33 AM PST, Matt Corallo <yalbrymrb@mattcorallo.com> wrote:
>>>
>>>
>>> On 6/9/25 9:57 AM, Matt Corallo wrote:
>>>>
>>>>
>>>> On 6/8/25 3:14 AM, Greg KH wrote:
>>>>> Have a pointer to that patch on lore for the maintainers involved to
>>>>> review?  Note, we are in the middle of the merge window, so no new
>>>>> changes can be added to our trees until -rc1 is out.
>>>>
>>>> A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ but that's the last he chimed in on this issue.
>>>
>>> Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on at least 6.18.
>>
>> Looking at the code, I think probably the best place to check would be in i2c_smbus_read_block_data() when it does a I2C_SMBUS_BLOCK_DATA cmd, since the callers are all already checking the returned status.
> 
> I believe that's what the above patch does?
> 

That wasn't a formal patch. I thought you had volunteered to submit one,
but my memory may defeat me and I may be wrong.

Guenter

Re: PMBus memory overflow

[Kees Cook]

On Sun, Mar 01, 2026 at 12:10:08PM -0500, Matt Corallo wrote:
> 
> 
> On 3/1/26 11:12 AM, Kees Cook wrote:
> > 
> > 
> > On March 1, 2026 5:46:33 AM PST, Matt Corallo <yalbrymrb@mattcorallo.com> wrote:
> > > 
> > > 
> > > On 6/9/25 9:57 AM, Matt Corallo wrote:
> > > > 
> > > > 
> > > > On 6/8/25 3:14 AM, Greg KH wrote:
> > > > > Have a pointer to that patch on lore for the maintainers involved to
> > > > > review?  Note, we are in the middle of the merge window, so no new
> > > > > changes can be added to our trees until -rc1 is out.
> > > > 
> > > > A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ but that's the last he chimed in on this issue.
> > > 
> > > Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on at least 6.18.
> > 
> > Looking at the code, I think probably the best place to check would be in i2c_smbus_read_block_data() when it does a I2C_SMBUS_BLOCK_DATA cmd, since the callers are all already checking the returned status.
> 
> I believe that's what the above patch does?

Sorry, I mis-pasted. I meant within i2c_smbus_xfer (rather than
i2c_smbus_read_block_data). Like:


diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index 71eb1ef56f0c..fbca606ba35a 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -547,6 +547,10 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
 			       command, protocol, data);
 	i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
 
+	if (WARN_ON_ONCE(res == 0 && command == I2C_SMBUS_BLOCK_DATA &&
+			 data->block[0] > I2C_SMBUS_BLOCK_MAX))
+		res = -E2BIG;
+
 	return res;
 }
 EXPORT_SYMBOL(i2c_smbus_xfer);

-- 
Kees Cook

Re: PMBus memory overflow

[Guenter Roeck]

On 3/1/26 21:09, Kees Cook wrote:
> On Sun, Mar 01, 2026 at 12:10:08PM -0500, Matt Corallo wrote:
>>
>>
>> On 3/1/26 11:12 AM, Kees Cook wrote:
>>>
>>>
>>> On March 1, 2026 5:46:33 AM PST, Matt Corallo <yalbrymrb@mattcorallo.com> wrote:
>>>>
>>>>
>>>> On 6/9/25 9:57 AM, Matt Corallo wrote:
>>>>>
>>>>>
>>>>> On 6/8/25 3:14 AM, Greg KH wrote:
>>>>>> Have a pointer to that patch on lore for the maintainers involved to
>>>>>> review?  Note, we are in the middle of the merge window, so no new
>>>>>> changes can be added to our trees until -rc1 is out.
>>>>>
>>>>> A proposed patch was posted by Guenter, and tested and confirmed that it fixes the issue by myself, at https://lore.kernel.org/linux-hwmon/284466fd-39e8-419e-8af5-41dbabb788af@roeck-us.net/ . Wolfram suggested this patch was acceptable at https://lore.kernel.org/linux-hwmon/aAtEydwUfVcE0XeA@shikoro/ but that's the last he chimed in on this issue.
>>>>
>>>> Any update on getting this patch applied Wolfram? Looks like the buffer overflow is still present on at least 6.18.
>>>
>>> Looking at the code, I think probably the best place to check would be in i2c_smbus_read_block_data() when it does a I2C_SMBUS_BLOCK_DATA cmd, since the callers are all already checking the returned status.
>>
>> I believe that's what the above patch does?
> 
> Sorry, I mis-pasted. I meant within i2c_smbus_xfer (rather than
> i2c_smbus_read_block_data). Like:
> 
> 
> diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
> index 71eb1ef56f0c..fbca606ba35a 100644
> --- a/drivers/i2c/i2c-core-smbus.c
> +++ b/drivers/i2c/i2c-core-smbus.c
> @@ -547,6 +547,10 @@ s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
>   			       command, protocol, data);
>   	i2c_unlock_bus(adapter, I2C_LOCK_SEGMENT);
>   
> +	if (WARN_ON_ONCE(res == 0 && command == I2C_SMBUS_BLOCK_DATA &&
> +			 data->block[0] > I2C_SMBUS_BLOCK_MAX))
> +		res = -E2BIG;
> +
>   	return res;
>   }
>   EXPORT_SYMBOL(i2c_smbus_xfer);
> 

Agreed, that makes more sense since it covers all callers, not just
i2c_smbus_read_block_data().

Guenter