All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] i2c: core: check returned size of emulated smbus block read
@ 2020-06-13 10:41 Mans Rullgard
  2020-06-26  8:22 ` Wolfram Sang
  0 siblings, 1 reply; 4+ messages in thread
From: Mans Rullgard @ 2020-06-13 10:41 UTC (permalink / raw)
  To: Wolfram Sang, linux-i2c; +Cc: linux-kernel

If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued
on some random device to return an arbitrary value in the first
byte (and nothing else).  When this happens, i2c_smbus_xfer_emulated()
will happily write past the end of the supplied data buffer, thus
causing Bad Things to happen.  To prevent this, check the size
before copying the data block and return an error if it is too large.

Fixes: 209d27c3b167 ("i2c: Emulate SMBus block read over I2C")
Signed-off-by: Mans Rullgard <mans@mansr.com>
---
 drivers/i2c/i2c-core-smbus.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/i2c/i2c-core-smbus.c b/drivers/i2c/i2c-core-smbus.c
index 3ac426a8ab5a..a719c26b98ac 100644
--- a/drivers/i2c/i2c-core-smbus.c
+++ b/drivers/i2c/i2c-core-smbus.c
@@ -495,6 +495,13 @@ static s32 i2c_smbus_xfer_emulated(struct i2c_adapter *adapter, u16 addr,
 			break;
 		case I2C_SMBUS_BLOCK_DATA:
 		case I2C_SMBUS_BLOCK_PROC_CALL:
+			if (msg[1].buf[0] > I2C_SMBUS_BLOCK_MAX) {
+				dev_err(&adapter->dev,
+					"Invalid block size returned: %d\n",
+					msg[1].buf[0]);
+				status = -EINVAL;
+				goto cleanup;
+			}
 			for (i = 0; i < msg[1].buf[0] + 1; i++)
 				data->block[i] = msg[1].buf[i];
 			break;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] i2c: core: check returned size of emulated smbus block read
  2020-06-13 10:41 [PATCH] i2c: core: check returned size of emulated smbus block read Mans Rullgard
@ 2020-06-26  8:22 ` Wolfram Sang
  2020-06-26 13:33   ` Måns Rullgård
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfram Sang @ 2020-06-26  8:22 UTC (permalink / raw)
  To: Mans Rullgard; +Cc: linux-i2c, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Sat, Jun 13, 2020 at 11:41:09AM +0100, Mans Rullgard wrote:
> If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
> them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued

Out of interest, which driver did you use?

> on some random device to return an arbitrary value in the first
> byte (and nothing else).  When this happens, i2c_smbus_xfer_emulated()
> will happily write past the end of the supplied data buffer, thus
> causing Bad Things to happen.  To prevent this, check the size
> before copying the data block and return an error if it is too large.

Good catch, we were relying on the drivers too much here. I think the
same fix is needed for the non-emulated case as well. Will have a look.

> +			if (msg[1].buf[0] > I2C_SMBUS_BLOCK_MAX) {
> +				dev_err(&adapter->dev,
> +					"Invalid block size returned: %d\n",
> +					msg[1].buf[0]);
> +				status = -EINVAL;

I changed this to -EPROTO as described in
Documentation/i2c/fault-codes.rst.

Applied to for-current, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] i2c: core: check returned size of emulated smbus block read
  2020-06-26  8:22 ` Wolfram Sang
@ 2020-06-26 13:33   ` Måns Rullgård
  2020-06-28 18:20     ` Wolfram Sang
  0 siblings, 1 reply; 4+ messages in thread
From: Måns Rullgård @ 2020-06-26 13:33 UTC (permalink / raw)
  To: Wolfram Sang; +Cc: linux-i2c, linux-kernel

Wolfram Sang <wsa@the-dreams.de> writes:

> On Sat, Jun 13, 2020 at 11:41:09AM +0100, Mans Rullgard wrote:
>> If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
>> them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued
>
> Out of interest, which driver did you use?

I saw it with the mv64xxx (Allwinner) and omap (Beaglebone) drivers.
From a quick look, it seems like quite a few others have the same
problem.

>> on some random device to return an arbitrary value in the first
>> byte (and nothing else).  When this happens, i2c_smbus_xfer_emulated()
>> will happily write past the end of the supplied data buffer, thus
>> causing Bad Things to happen.  To prevent this, check the size
>> before copying the data block and return an error if it is too large.
>
> Good catch, we were relying on the drivers too much here. I think the
> same fix is needed for the non-emulated case as well. Will have a look.
>
>> +			if (msg[1].buf[0] > I2C_SMBUS_BLOCK_MAX) {
>> +				dev_err(&adapter->dev,
>> +					"Invalid block size returned: %d\n",
>> +					msg[1].buf[0]);
>> +				status = -EINVAL;
>
> I changed this to -EPROTO as described in
> Documentation/i2c/fault-codes.rst.
>
> Applied to for-current, thanks!
>

-- 
Måns Rullgård

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] i2c: core: check returned size of emulated smbus block read
  2020-06-26 13:33   ` Måns Rullgård
@ 2020-06-28 18:20     ` Wolfram Sang
  0 siblings, 0 replies; 4+ messages in thread
From: Wolfram Sang @ 2020-06-28 18:20 UTC (permalink / raw)
  To: Måns Rullgård; +Cc: linux-i2c, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]


> I saw it with the mv64xxx (Allwinner) and omap (Beaglebone) drivers.
> From a quick look, it seems like quite a few others have the same
> problem.

Okay, well, to be fair, both drivers don't advertise
I2C_SMBUS_BLOCK_DATA. The client driver should check for that. Anyhow,
it makes sense to have your additional check in the core as fallback
safety.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-06-28 18:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-13 10:41 [PATCH] i2c: core: check returned size of emulated smbus block read Mans Rullgard
2020-06-26  8:22 ` Wolfram Sang
2020-06-26 13:33   ` Måns Rullgård
2020-06-28 18:20     ` Wolfram Sang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.