Re: I2C_M_RECV_LEN for i2c-mxs

["Uwe Kleine-König" <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

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/  |