[PATCH] i2c-core: Expand buffers used in i2c_smbus_xfer_emulated()
xow at google.com
Sat Mar 11 08:17:56 AEDT 2017
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
CPU: 0 PID: 1559 Comm: zaius_vcs.sh Not tainted
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.
More information about the openbmc