Re: PMBus memory overflow

[Matt Corallo <yalbrymrb@mattcorallo.com>]

On 4/17/25 9:21 PM, Guenter Roeck wrote:
> On 4/17/25 11:14, Matt Corallo wrote:
>> I do not, sadly (though FSP support has been rumored to help out at least marginally, though they 
>> haven't been useful for me). Interestingly the (I guess ancient now) pmbus_peek.c script has no 
>> issues reading from it (added a quick print on the -E2BIG line and it didn't get hit). 
>> pmbuss_peek.c says the following:
>>
>> root@rackchill-refresh:~# ./a.out -b /dev/i2c-3 -s 0x59
>> PMBus slave on /dev/i2c-3, address 0x59
>>
> 
> pmbus_peek supports reading up to 255 bytes into the receive buffer.

Hmm, I'm using this version, which on L622 checks for a length > 32 (and doesn't get hit in the -s 
command) - https://github.com/jktjkt/pmbus_peek/blob/master/pmbus_peek.c#L622

> Anything above 32 bytes violates the SMBus specification. I found that
> the I2C controller driver should block that. If it doesn't, all kinds
> of chips could trigger this problem. Do you know which I2C controller
> is used by that system ? You mentioned an SMBus - USB adapter. The drivers
> for the adapters I am aware of (Diolan, Devantech) do validate the return
> length, so I assume you use something else or maybe an out-of-tree driver.

The driver appears to be in-tree (or at least was auto-loaded by the Proxmox kernel, which is mostly 
just the Ubuntu kernel). Its a 10c4:ea90 Silicon Labs CP2112 HID I2C Bridge.

Still, more generally, presumably it shouldn't be the case that a defective USB device can cause the 
kernel to memcpy past a buffer? I guess for hardened kernels it gets caught (though once the process 
gets killed by the hardening the system is still somewhat shaky, reboots dont work etc), but is 
there a build option that would turn this into a security vuln?

Matt