[PATCH] i2c-core: Expand buffers used in i2c_smbus_xfer_emulated()

[Cédric Le Goater]

On 03/10/2017 10:17 PM, Xo Wang wrote:
> On Fri, Mar 10, 2017 at 6:20 AM, Cédric Le Goater <clg at kaod.org> wrote:
>> On 03/10/2017 02:38 PM, Cédric Le Goater wrote:
>>> On 03/10/2017 01:21 PM, Andrew Jeffery wrote:
>>>> Protect against suspect hardware causing the bus to read off more data
>>>> than defined in the SMBus specification.
>>>>
>>>> Some investigation that suggests that the DEVICE_ID command (0xfd) to
>>>> a UCD9000 occasionally returns all 0xff, causing the bus driver to
>>>> overrun the 34-byte data buffer provided by the I2C core with a 255-byte
>>>> broken response. This patch should prevent trashing the stack and also
>>>> cause the UCD9000's probe to fail.
>>>>
> 
> Excellent. We tracked down failures to the same error, that the
> occasional 0xff from the UCD is interpreted as SMBus block length.
> However, the symptom we observed for the overrun is a kernel panic:
> 
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted
> in: 802e5e38
> 
> CPU: 0 PID: 1559 Comm: zaius_vcs.sh Not tainted
> 4.7.10-f26558191540830589fe03932d05577957670b8d #2
> Hardware name: ASpeed SoC
> [<801072f8>] (unwind_backtrace) from [<80105558>] (show_stack+0x10/0x14)
> [<80105558>] (show_stack) from [<8016d06c>] (panic+0xb8/0x248)
> [<8016d06c>] (panic) from [<80110df4>] (__stack_chk_fail+0x10/0x14)
> [<80110df4>] (__stack_chk_fail) from [<802e5e38>] (i2c_smbus_xfer+0x508/0x54c)
> [<802e5e38>] (i2c_smbus_xfer) from [<ffffffff>] (0xffffffff)
> 
> I'm not sure that the UCD probe failures are totally related to the
> bug that this patch fixes.

No. I think the device is sometimes quite slow to respond and also 
the bus recovery path seems a bit fragile.

C.