Hi Wolfram, On Sun, Apr 14, 2013 at 01:57:58PM +0200, Wolfram Sang wrote: > > Ah, ok. But then there is a different problem: Even though "my" driver > > only advertises I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL calling > > i2c_smbus_read_block_data in userspace results in .master_xfer being > > called with I2C_M_RECV_LEN set. > > From Documentation/i2c/functionality: > > Because not every I2C or SMBus adapter implements everything in the > I2C specifications, a client can not trust that everything it needs > is implemented when it is given the option to attach to an adapter: > the client needs some way to check whether an adapter has the needed > functionality... While add support for I2C_M_RECV_LEN I forgot to write the length data to the first byte in the message buffer which happend to be initialized with 0xff. This made i2c_smbus_xfer_emulated copy 255 bytes to data->block overflowing the array and so resulting in stack curruption. I think the same could be accomplished with a non-broken driver (e.g. by calling i2c_smbus_read_block_data for an eeprom that is interpreted as a 1 byte read by the i2c bus driver. If the read byte is big enough the same stack curruption occurs). So IMHO the i2c core should be a bit more careful here and either not let i2c_smbus_xfer_emulated call the xfer callback of a driver that is not capable to handle I2C_M_RECV_LEN with a message that has this bit set or at least assert that data->block isn't written to out of bounds. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
