Hi Wolfram, > On Wed, Nov 15, 2017 at 12:54:09PM -0700, Compostella, Jeremy wrote: > > On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is > > greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes > greater or equal? > > data out of the msgbuf1 boundary. > > > > It is possible from a user application to run into that issue by call > > the I2C_SMBUS ioctl with data.block[0] greater than > > I2C_SMBUS_BLOCK_MAX + 1. > ditto? Actually, this is a bit more complicated. Theoretically it should be "greater than I2C_SMBUS_BLOCK_MAX". The documentation (Documentation/i2c/dev-interface) says "The block buffers need not be longer than 32 bytes". However, in practice, The i2c_smbus_xfer_emulated() function defines: unsigned char msgbuf1[I2C_SMBUS_BLOCK_MAX+2]; It uses the first element to store the requested length. Therefore, in practice, we hit the issue with "greater than I2C_SMBUS_BLOCK_MAX + 1". > Basically good, yet to make the code easier to read I'd suggest > something like this? Untested, wanted to hear your opinion first. > drivers/i2c/i2c-core-smbus.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c > index 4bb9927afd0106..5fc5ddd965434f 100644 > --- a/drivers/i2c/i2c-core-smbus.c > +++ b/drivers/i2c/i2c-core-smbus.c > @@ -397,16 +397,16 @@ static s32 i2c_smbus_xfer_emulated(struct i2c_adapter *adapter, u16 addr, > the underlying bus driver */ > break; > case I2C_SMBUS_I2C_BLOCK_DATA: > + if (data->block[0] > I2C_SMBUS_BLOCK_MAX) { > + dev_err(&adapter->dev, "Invalid block size %d\n", > + data->block[0]); > + return -EINVAL; > + } > + > if (read_write == I2C_SMBUS_READ) { > msg[1].len = data->block[0]; > } else { > msg[0].len = data->block[0] + 1; > - if (msg[0].len > I2C_SMBUS_BLOCK_MAX + 1) { > - dev_err(&adapter->dev, > - "Invalid block write size %d\n", > - data->block[0]); > - return -EINVAL; > - } > for (i = 1; i <= data->block[0]; i++) > msgbuf0[i] = data->block[i]; > } This is a better option, I think I have made such a version at some points but did not want to touch the other case for some reasons that I cannot remember now :/ I have a added a little c ternary instruction to keep the same level of debug/error information. If you don't like it we can remove it. I have updated, tested and attached the new version to this email. I also improved the commit message by adding some information about what is expected by the documentation. I don't know what is the process to update the patch to the mailing list. Should I send a new email with the new patch instead ? Thanks, Jeremy