From: Dan Carpenter <dan.carpenter@oracle.com>
To: Michael Zaidman <michael.zaidman@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-i2c@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [bug report] HID: ft260: add usb hid to i2c host bridge driver
Date: Mon, 12 Apr 2021 12:11:51 +0300 [thread overview]
Message-ID: <20210412091151.GV6048@kadam> (raw)
In-Reply-To: <20210410210425.GA4073@michael-VirtualBox>
On Sun, Apr 11, 2021 at 12:04:25AM +0300, Michael Zaidman wrote:
> 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?
Could you just give me a Reported-by tag? Thanks!
regards,
dan carpenter
next prev parent reply other threads:[~2021-04-12 9:18 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
2021-04-12 9:11 ` Dan Carpenter [this message]
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=20210412091151.GV6048@kadam \
--to=dan.carpenter@oracle.com \
--cc=benjamin.tissoires@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=michael.zaidman@gmail.com \
/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 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.