On Thu, 21 Jun 2018 18:03:24 +0300, Pasha Orehov wrote: > On i2c_smbus_read_block my device sometimes returns FFs, so kernel > writes results out of buffer and halts. So it may be treated as > security hole too. This code exists since v2.6 > Please mitigate me. :) > > --- i2c-core-smbus-linus.c 2018-06-21 17:04:10.620609631 +0300 > +++ i2c-core-smbus.c 2018-06-21 17:22:23.145417235 +0300 > @@ -226,7 +226,7 @@ > if (status) > return status; > > - memcpy(values, &data.block[1], data.block[0]); > + memcpy(values, &data.block[1], min(data.block[0], sizeof(data))); > return data.block[0]; > } > EXPORT_SYMBOL(i2c_smbus_read_block_data); > @@ -494,7 +494,7 @@ > break; > case I2C_SMBUS_BLOCK_DATA: > case I2C_SMBUS_BLOCK_PROC_CALL: > - for (i = 0; i < msg[1].buf[0] + 1; i++) > + for (i = 0; i < min(sizeof(i2c_smbus_data), msg[1].buf[0] > + 1); i++) > data->block[i] = msg[1].buf[i]; > break; > } Please send patches in proper format (full path to files, diff option -p to include function names, and no line wrapping by your email client.) I am also curious which i2c bus driver you are using. It is the bus driver which should ensure that the block length returned by the I2C slave device is within the specifications. If your bus driver receives 0xff as the length, blindly writes that to data.block[0] and keeps processing, it is buggy, and you must be hitting some kind of buffer overrun inside the bus driver already. Trying to fix that in i2c-core is too late, and redundant for all bus drivers which do the right thing. -- Jean Delvare SUSE L3 Support
