Re: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25.01.2018 13:25, Dan Carpenter wrote:
> On Thu, Jan 25, 2018 at 10:58:45AM +0100, Andrzej Hajda wrote:
>> On 23.01.2018 09:32, Dan Carpenter wrote:
>>> Hello Andrzej Hajda,
>>>
>>> The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to
>>> identify last buffers in decoder capture queue" from Oct 7, 2015,
>>> leads to the following static checker warning:
>>>
>>> 	drivers/media/platform/s5p-mfc/s5p_mfc_dec.c:658 vidioc_dqbuf()
>>> 	error: buffer overflow 'ctx->dst_bufs' 32 user_rl = '0-u32max'
>>>
>>> drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
>>>    635  /* Dequeue a buffer */
>>>    636  static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
>>>    637  {
>>>    638          const struct v4l2_event ev = {
>>>    639                  .type = V4L2_EVENT_EOS
>>>    640          };
>>>    641          struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
>>>    642          int ret;
>>>    643  
>>>    644          if (ctx->state == MFCINST_ERROR) {
>>>    645                  mfc_err_limited("Call on DQBUF after unrecoverable error\n");
>>>    646                  return -EIO;
>>>    647          }
>>>    648  
>>>    649          switch (buf->type) {
>>>    650          case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>>>    651                  return vb2_dqbuf(&ctx->vq_src, buf, file->f_flags & O_NONBLOCK);
>>>    652          case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>>>    653                  ret = vb2_dqbuf(&ctx->vq_dst, buf, file->f_flags & O_NONBLOCK);
>>>    654                  if (ret)
>>>    655                          return ret;
>>>    656  
>>>    657                  if (ctx->state == MFCINST_FINISHED &&
>>>    658                      (ctx->dst_bufs[buf->index].flags & MFC_BUF_FLAG_EOS))
>>>                                            ^^^^^^^^^^
>>> Smatch is complaining that "buf->index" is not capped.  So far as I can
>>> see this is true.  I would have expected it to be checked in
>>> check_array_args() or video_usercopy() but I couldn't find the check.
>> I did not work in V4L2 area for long time, so I could be wrong, but I
>> hope the code is correct, below my explanation.
>> User provides only type, memory and reserved fields in buf, other fields
>> are filled by vb2_dqbuf (line 653) core function, ie index field is
>> copied from buffer which was queued by qbuf.
>> And vidioc_qbuf calls vb2_qbuf, which calls vb2_queue_or_prepare_buf,
>> which checks index bounds [1].
>>
>> So I suppose this code is correct.
>> Btw, I have also looked at other drivers and it looks omap driver
>> handles it incorrectly, ie it uses index field provided by user -
>> possible memory leak. CC Hans and Mauro, since there is no driver
>> maintainer of OMAP.
>>
>> Btw2, is it possible to check in smatch which fields of passed struct
>> given callback can read or fill ? For example here API restrict dqbuf
>> callback to read only three fields of buf, and fill the others.
>>
>> [1]:
>> http://elixir.free-electrons.com/linux/latest/source/drivers/media/v4l2-core/videobuf2-v4l2.c#L165
>> [2]:
>> http://elixir.free-electrons.com/linux/latest/source/drivers/media/platform/omap/omap_vout.c#L1520
>>
>> Regards
>> Andrzej
> Smatch does track the feilds...  Smatch sees that buf->index is capped
> in vidioc_qbuf() but it still complains that buf->index gets set by the
> user in the ioctl and not checked before we use it vb2_dqbuf().  The
> call tree looks like this:
>
> --> video_usercopy()
>     Copies _IOC_SIZE(cmd) bytes to parg.  The _IOC_SIZE() is
>     sizeof(struct v4l2_buffer) so all the feilds are reset.  Smatch
>     doesn't track how many bytes the users controls, it just marks
>     everything in *parg as tainted but it doesn't matter in this case
>     since all the feilds are set.
>     video_usercopy() calls err = func(file, cmd, parg);
>
>     --> __video_do_ioctl()
>         calls info->u.func(ops, file, fh, arg);
>
>         --> v4l_dqbuf()
>             calls ops->vidioc_dqbuf(file, fh, p);
>
>             --> vidioc_dqbuf()

In our case s5p_mfc_dec.c:vidioc_dqbuf

>                 uses unchecked buf->index

No, it uses only buf->type (it is correct usage), then calls
vb2_dqbuf(which should fill index and other fields with proper values),
and then uses .index.

> Ah...  Hm.  Is it the call to vb2_core_dqbuf() which limits buf->index?

No, buf->index is bound checked at buffer queuing:
s5p_mfc_dec.c:vidioc_qbuf
    vb2_qbuf
        vb2_queue_or_prepare_buf

> I don't see a path from vb2_core_dqbuf() to vb2_qbuf() but I may have
> missed it.

It is reverse:
s5p_mfc_dec.c:vidioc_dqbuf
    vb2_dqbuf
        vb2_core_dqbuf

Regards
Andrzej

>
> regards,
> dan carpenter
>
>
>
>




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux