All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Michael Zaidman <michael.zaidman@gmail.com>
Cc: 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: Sat, 10 Apr 2021 18:37:13 +0300	[thread overview]
Message-ID: <20210410153712.GQ6048@kadam> (raw)
In-Reply-To: <20210410122729.GA6136@michael-VirtualBox>

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.

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



  reply	other threads:[~2021-04-10 15:37 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 [this message]
2021-04-10 21:04     ` Michael Zaidman
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=20210410153712.GQ6048@kadam \
    --to=dan.carpenter@oracle.com \
    --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.