Hi Michael, On Thu, Dec 27, 2018 at 12:53 PM Michael Hanselmann <pub...@hansmi.ch> wrote: > The "eeprom_write_data" function in "smbus_eeprom.c" had no provisions > to limit the length of data written. If a caller were able to manipulate > the "len" parameter they could potentially write before or after the > target buffer.
You forgot to sign your commit: "Signed-off-by: Michael Hanselmann <pub...@hansmi.ch>" (See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297) > --- > hw/i2c/smbus_eeprom.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c > index f18aa3de35..74fa1c328c 100644 > --- a/hw/i2c/smbus_eeprom.c > +++ b/hw/i2c/smbus_eeprom.c > @@ -76,6 +76,7 @@ static void eeprom_write_data(SMBusDevice *dev, uint8_t > cmd, uint8_t *buf, int l > It is a block write without a length byte. Fortunately we > get the full block anyway. */ > /* TODO: Should this set the current location? */ > + len &= 0xff; > if (cmd + len > 256) Corey Minyard sent a cleanup series [1] because this device model is known to be unsafe and need rewrite. There is a particular patch [2] which add the SMBUS_EEPROM_SIZE definition. He also provided a intent at cleaning this problem here [3] where Peter suggested to split it in fewer patches. Regards, Phil. [1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05293.html [2] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05295.html [3] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg05298.html > n = 256 - cmd; > else > -- > 2.11.0 > >