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

[Xo Wang]

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.

cheers
xo