From: Michael Zaidman <michael.zaidman@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-i2c@vger.kernel.org, linux-input@vger.kernel.org,
michael.zaidman@gmail.com
Subject: Re: [bug report] HID: ft260: add usb hid to i2c host bridge driver
Date: Sun, 11 Apr 2021 00:04:25 +0300 [thread overview]
Message-ID: <20210410210425.GA4073@michael-VirtualBox> (raw)
In-Reply-To: <20210410153712.GQ6048@kadam>
On Sat, Apr 10, 2021 at 06:37:13PM +0300, Dan Carpenter wrote:
> On Sat, Apr 10, 2021 at 03:27:29PM +0300, Michael Zaidman wrote:
> > On Fri, Apr 09, 2021 at 03:32:06PM +0300, Dan Carpenter wrote:
> > > Hello Michael Zaidman,
> > >
> > > The patch 6a82582d9fa4: "HID: ft260: add usb hid to i2c host bridge
> > > driver" from Feb 19, 2021, leads to the following static checker
> > > warning:
> > >
> > > drivers/hid/hid-ft260.c:441 ft260_smbus_write()
> > > error: '__memcpy()' '&rep->data[1]' too small (59 vs 255)
> > >
> > > drivers/hid/hid-ft260.c
> > > 423 static int ft260_smbus_write(struct ft260_device *dev, u8 addr, u8 cmd,
> > > 424 u8 *data, u8 data_len, u8 flag)
> > > 425 {
> > > 426 int ret = 0;
> > > 427 int len = 4;
> > > 428
> > > 429 struct ft260_i2c_write_request_report *rep =
> > > 430 (struct ft260_i2c_write_request_report *)dev->write_buf;
> > > 431
> > > 432 rep->address = addr;
> > > 433 rep->data[0] = cmd;
> > > 434 rep->length = data_len + 1;
> > > 435 rep->flag = flag;
> > > 436 len += rep->length;
> > > 437
> > > 438 rep->report = FT260_I2C_DATA_REPORT_ID(len);
> > > 439
> > > 440 if (data_len > 0)
> > > 441 memcpy(&rep->data[1], data, data_len);
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > Smatch says that this can be called from the i2cdev_ioctl_smbus()
> > > function.
> >
> > Hi Dan,
> >
> > This is an example of a false-positive static checker warning.
> >
> > The maximum data size that the i2cdev_ioctl_smbus() can pass to the
> > i2c_smbus_xfer() is sizeof(data->block) which is (I2C_SMBUS_BLOCK_MAX + 2)
> > or 34 bytes. Thus, no need to check the data_len against 59 here.
> >
> > >
> > > i2cdev_ioctl_smbus()
> > > --> i2c_smbus_xfer
> > > --> __i2c_smbus_xfer
> > > --> ft260_smbus_xfer
> > > --> ft260_smbus_write
>
> It's actually me who misunderstood the Smatch warning. Smatch is not
> complaining about data_len, it's data->block[0] which is user
> controlled and only for the I2C_SMBUS_I2C_BLOCK_DATA command.
>
> The call tree is the same. I've looked at it again. Here is how
> i2cdev_ioctl_smbus() looks like:
>
> drivers/i2c/i2c-dev.c
> 355 return -EINVAL;
> 356 }
> 357
> 358 if ((size == I2C_SMBUS_BYTE_DATA) ||
> 359 (size == I2C_SMBUS_BYTE))
> 360 datasize = sizeof(data->byte);
> 361 else if ((size == I2C_SMBUS_WORD_DATA) ||
> 362 (size == I2C_SMBUS_PROC_CALL))
> 363 datasize = sizeof(data->word);
> 364 else /* size == smbus block, i2c block, or block proc. call */
> 365 datasize = sizeof(data->block);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 366
> 367 if ((size == I2C_SMBUS_PROC_CALL) ||
> 368 (size == I2C_SMBUS_BLOCK_PROC_CALL) ||
> 369 (size == I2C_SMBUS_I2C_BLOCK_DATA) ||
> ^^^^^^^^^^^^^^^^^^^^^^^^
> 370 (read_write == I2C_SMBUS_WRITE)) {
> 371 if (copy_from_user(&temp, data, datasize))
> ^^^^
> temp.block[0] is user controlled.
>
> 372 return -EFAULT;
> 373 }
> 374 if (size == I2C_SMBUS_I2C_BLOCK_BROKEN) {
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 375 /* Convert old I2C block commands to the new
> 376 convention. This preserves binary compatibility. */
> 377 size = I2C_SMBUS_I2C_BLOCK_DATA;
> 378 if (read_write == I2C_SMBUS_READ)
> 379 temp.block[0] = I2C_SMBUS_BLOCK_MAX;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Except for size BROKEN
>
> 380 }
> 381 res = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> 382 read_write, command, size, &temp);
> ^^^^^
>
> 383 if (!res && ((size == I2C_SMBUS_PROC_CALL) ||
> 384 (size == I2C_SMBUS_BLOCK_PROC_CALL) ||
> 385 (read_write == I2C_SMBUS_READ))) {
> 386 if (copy_to_user(data, &temp, datasize))
> 387 return -EFAULT;
> 388 }
>
> The rest of the call tree seems straight forward but it's possible I
> have missed somewhere that checks data[0]. Here is how ft260_smbus_xfer()
> looks like.
Oh, you are right. Despite that the SMbus block transaction limits the maximum
number of bytes to 32, nothing prevents a user from specifying via ioctl a larger
data size than the ft260 can handle in a single transfer.
I am going to fix it in the ft260_smbus_write (with your Signed-off-by), but
perhaps we should fix it in the first place, in the i2cdev_ioctl_smbus routine?
What do you think?
>
> drivers/hid/hid-ft260.c
> 655 case I2C_SMBUS_BLOCK_DATA:
> 656 if (read_write == I2C_SMBUS_READ) {
> 657 ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,
> 658 FT260_FLAG_START);
> 659 if (ret)
> 660 goto smbus_exit;
> 661
> 662 ret = ft260_i2c_read(dev, addr, data->block,
> 663 data->block[0] + 1,
> 664 FT260_FLAG_START_STOP_REPEATED);
> 665 } else {
> 666 ret = ft260_smbus_write(dev, addr, cmd, data->block,
> 667 data->block[0] + 1,
> 668 FT260_FLAG_START_STOP);
> 669 }
> 670 break;
> 671 case I2C_SMBUS_I2C_BLOCK_DATA:
> 672 if (read_write == I2C_SMBUS_READ) {
> 673 ret = ft260_smbus_write(dev, addr, cmd, NULL, 0,
> 674 FT260_FLAG_START);
> 675 if (ret)
> 676 goto smbus_exit;
> 677
> 678 ret = ft260_i2c_read(dev, addr, data->block + 1,
> 679 data->block[0],
> 680 FT260_FLAG_START_STOP_REPEATED);
> 681 } else {
> 682 ret = ft260_smbus_write(dev, addr, cmd, data->block + 1,
> 683 data->block[0],
> ^^^^^^^^^^^^^^
> Boom. Dead.
>
> 684 FT260_FLAG_START_STOP);
> 685 }
> 686 break;
> 687 default:
> 688 hid_err(hdev, "unsupported smbus transaction size %d\n", size);
> 689 ret = -EOPNOTSUPP;
> 690 }
>
> regards,
> dan carpenter
>
>
next prev parent reply other threads:[~2021-04-10 21:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 12:32 [bug report] HID: ft260: add usb hid to i2c host bridge driver Dan Carpenter
2021-04-10 12:27 ` Michael Zaidman
2021-04-10 15:37 ` Dan Carpenter
2021-04-10 21:04 ` Michael Zaidman [this message]
2021-04-12 9:11 ` Dan Carpenter
2021-04-13 15:52 ` Michael Zaidman
-- strict thread matches above, loose matches on Subject: below --
2021-03-18 10:39 Dan Carpenter
2021-03-19 16:33 ` Michael Zaidman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210410210425.GA4073@michael-VirtualBox \
--to=michael.zaidman@gmail.com \
--cc=benjamin.tissoires@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=jikos@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).