From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Robb Glasser <rglasser@google.com>
Subject: Re: [media] uvcvideo: Prevent heap overflow in uvc driver
Date: Wed, 28 Jun 2017 21:18:37 +0300 [thread overview]
Message-ID: <1612560.vxfrDdQTFq@avalon> (raw)
In-Reply-To: <1797631.lsAEjhpLaU@avalon>
Hi Guenter,
On Wednesday 28 Jun 2017 20:59:17 Laurent Pinchart wrote:
> On Wednesday 28 Jun 2017 07:36:43 Guenter Roeck wrote:
> > On Mon, May 22, 2017 at 12:48:04PM -0700, Guenter Roeck wrote:
> >> From: Robb Glasser <rglasser@google.com>
> >>
> >> The size of uvc_control_mapping is user controlled leading to a
> >> potential heap overflow in the uvc driver. This adds a check to verify
> >> the user provided size fits within the bounds of the defined buffer
> >> size.
> >>
> >> Signed-off-by: Robb Glasser <rglasser@google.com>
> >> [groeck: cherry picked from
> >>
> >> https://source.codeaurora.org/quic/la/kernel/msm-3.10
> >> commit b7b99e55bc7770187913ed092990852ea52d7892;
> >> updated subject]
> >>
> >> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> >> ---
> >> Fixes CVE-2017-0627.
> >
> > Please do not apply this patch. It is buggy.
>
> I apologize for not noticing the initial patch, even if it looks like it was
> all for the best. Will you send a new version ?
>
> >> drivers/media/usb/uvc/uvc_ctrl.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> >> b/drivers/media/usb/uvc/uvc_ctrl.c index c2ee6e39fd0c..252ab991396f
> >> 100644
> >> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> >> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> >> @@ -1992,6 +1992,9 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> >> *chain,
> >> if (!found)
> >> return -ENOENT;
> >>
> >> + if (ctrl->info.size < mapping->size)
> >> + return -EINVAL;
> >> +
By the way, I believe the right fix should be
if (mapping->offset + mapping->size > ctrl->info.size * 8)
return -EINVAL;
Both mapping->offset and mapping->size are 8-bit integers, so there's no risk
of overflow in the addition. If we want to safeguard against a possible future
bug if the type of the fields change, we could add
if (mapping->offset + mapping->size < mapping->offset)
return -EINVAL;
> >> if (mutex_lock_interruptible(&chain->ctrl_mutex))
> >> return -ERESTARTSYS;
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-06-28 18:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 19:48 [PATCH] [media] uvcvideo: Prevent heap overflow in uvc driver Guenter Roeck
2017-06-28 14:36 ` Guenter Roeck
2017-06-28 17:59 ` Laurent Pinchart
2017-06-28 18:18 ` Laurent Pinchart [this message]
2017-06-28 20:26 ` Guenter Roeck
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=1612560.vxfrDdQTFq@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mchehab@kernel.org \
--cc=rglasser@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox