linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ricardo Ribalda <ribalda@chromium.org>,
	ionut_n2001@yahoo.com, Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH] media: uvcvideo: Silence memcpy() run-time false positive warnings
Date: Sat, 7 Jan 2023 03:42:38 +0200	[thread overview]
Message-ID: <Y7jODnbUqCwfwwHI@pendragon.ideasonboard.com> (raw)
In-Reply-To: <202301061217.816FC0313D@keescook>

Hello,

On Fri, Jan 06, 2023 at 12:19:01PM -0800, Kees Cook wrote:
> On Fri, Jan 06, 2023 at 12:43:44PM +0100, Ricardo Ribalda wrote:
> > On Fri, 6 Jan 2023 at 07:19, Kees Cook wrote:
> > >
> > > The memcpy() in uvc_video_decode_meta() intentionally copies across the
> > > length and flags members and into the trailing buf flexible array.
> > > Split the copy so that the compiler can better reason about (the lack
> > > of) buffer overflows here. Avoid the run-time false positive warning:
> > >
> > >   memcpy: detected field-spanning write (size 12) of single field "&meta->length" at drivers/media/usb/uvc/uvc_video.c:1355 (size 1)
> > >
> > > Additionally fix a typo in the documentation for struct uvc_meta_buf.
> > >
> > > Reported-by: ionut_n2001@yahoo.com
> > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=216810
> > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> > > Cc: linux-media@vger.kernel.org
> > > Signed-off-by: Kees Cook <keescook@chromium.org>
> > > ---
> > >  drivers/media/usb/uvc/uvc_video.c | 4 +++-
> > >  include/uapi/linux/uvcvideo.h     | 2 +-
> > >  2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > > index d2eb9066e4dc..b67347ab4181 100644
> > > --- a/drivers/media/usb/uvc/uvc_video.c
> > > +++ b/drivers/media/usb/uvc/uvc_video.c
> > > @@ -1352,7 +1352,9 @@ static void uvc_video_decode_meta(struct uvc_streaming *stream,
> > >         if (has_scr)
> > >                 memcpy(stream->clock.last_scr, scr, 6);
> > >
> > > -       memcpy(&meta->length, mem, length);
> > > +       meta->length = mem[0];
> > > +       meta->flags  = mem[1];
> > > +       memcpy(meta->buf, &mem[2], length - 2);
> > >         meta_buf->bytesused += length + sizeof(meta->ns) + sizeof(meta->sof);
> > >
> > >         uvc_dbg(stream->dev, FRAME,
> > > diff --git a/include/uapi/linux/uvcvideo.h b/include/uapi/linux/uvcvideo.h
> > > index 8288137387c0..a9d0a64007ba 100644
> > > --- a/include/uapi/linux/uvcvideo.h
> > > +++ b/include/uapi/linux/uvcvideo.h
> > > @@ -86,7 +86,7 @@ struct uvc_xu_control_query {
> > >   * struct. The first two fields are added by the driver, they can be used for
> > >   * clock synchronisation. The rest is an exact copy of a UVC payload header.
> > >   * Only complete objects with complete buffers are included. Therefore it's
> > > - * always sizeof(meta->ts) + sizeof(meta->sof) + meta->length bytes large.
> > > + * always sizeof(meta->ns) + sizeof(meta->sof) + meta->length bytes large.
> > >   */
> > >  struct uvc_meta_buf {
> > >         __u64 ns;
> > [...]
> >
> > Would it make more sense to replace *mem with a structure/union. Something like:
> > https://patchwork.linuxtv.org/project/linux-media/patch/20221214-uvc-status-alloc-v4-0-f8e3e2994ebd@chromium.org/
> 
> I wasn't sure -- it seemed like this routine was doing the serializing
> into a struct already and an additional struct overlay wasn't going to
> improve readability. But I can certainly do that if it's preferred!

I'm not sure to see how using an additional struct or union would help.
We can't use struct assignment as the data may be unaligned, so memcpy()
is required. The issue isn't with the source operand of the memcpy() but
with the destination operand. Ricardo, if I'm missing something, please
submit an alternative patch to explain what you meant.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-01-07  1:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06  6:17 [PATCH] media: uvcvideo: Silence memcpy() run-time false positive warnings Kees Cook
2023-01-06 11:43 ` Ricardo Ribalda
2023-01-06 20:19   ` Kees Cook
2023-01-07  1:42     ` Laurent Pinchart [this message]
2023-01-09 10:46       ` Ricardo Ribalda
2023-02-07 22:06         ` Andy Shevchenko
2023-02-22 13:14           ` Ricardo Ribalda

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=Y7jODnbUqCwfwwHI@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=ionut_n2001@yahoo.com \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ribalda@chromium.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).