From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-media@vger.kernel.org, kernel-janitors@vger.kernel.org,
stable@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
Date: Thu, 15 Dec 2011 09:21:41 +0000 [thread overview]
Message-ID: <4EE9BC25.7020303@infradead.org> (raw)
In-Reply-To: <20111215063445.GA2424@elgon.mountain>
On 15-12-2011 04:34, Dan Carpenter wrote:
> On a 32bit system the multiplication here could overflow. p->count is
> used in some of the V4L drivers.
ULONG_MAX / sizeof(v4l2_ext_control) is too much. This ioctl is used on things
like setting MPEG paramenters, where several parameters need adjustments at
the same time. I risk to say that 64 is probably a reasonably safe upper limit.
Btw, the upstream code also seems to have the same issue:
static int check_array_args(unsigned int cmd, void *parg, size_t *array_size,
void * __user *user_ptr, void ***kernel_ptr)
{
...
if (ctrls->count != 0) {
...
*array_size = sizeof(struct v4l2_ext_control)
* ctrls->count;
ret = 1;
...
}
long
video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
v4l2_kioctl func)
{
...
err = check_array_args(cmd, parg, &array_size, &user_ptr, &kernel_ptr);
if (err < 0)
goto out;
has_array_args = err;
if (has_array_args) {
mbuf = kmalloc(array_size, GFP_KERNEL);
...
so, if is there any overflow at check_array_args(), instead of returning
an error to userspace, it will allocate the array with less space than
needed.
On both upstream and longterm, I think that it is more reasonable to
state a limit for the maximum number of controls that can be passed at
the same time, and live with that.
A dummy check says:
$ more include/linux/videodev2.h |grep V4L2_CID|wc -l
209
So, an upper limit of 256 is enough to allow userspace to change all existing controls
at the same time.
The proper way seems to add a define at include/linux/videodev2.h
and enforce it at the usercopy code.
Regards,
Mauro
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> This is a patch against the 2.6.32-longterm kernel. In the stock
> kernel, this code was totally rewritten and fixed in 2010 by d14e6d76ebf
> "[media] v4l: Add multi-planar ioctl handling code".
>
> Hopefully, someone can Ack this and we merge it into the stable tree.
>
> diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
> index 265bfb5..7196303 100644
> --- a/drivers/media/video/v4l2-ioctl.c
> +++ b/drivers/media/video/v4l2-ioctl.c
> @@ -414,6 +414,9 @@ video_usercopy(struct file *file, unsigned int cmd, unsigned long arg,
> p->error_idx = p->count;
> user_ptr = (void __user *)p->controls;
> if (p->count) {
> + err = -EINVAL;
> + if (p->count > ULONG_MAX / sizeof(struct v4l2_ext_control))
> + goto out_ext_ctrl;
> ctrls_size = sizeof(struct v4l2_ext_control) * p->count;
> /* Note: v4l2_ext_controls fits in sbuf[] so mbuf is still NULL. */
> mbuf = kmalloc(ctrls_size, GFP_KERNEL);
> @@ -1912,6 +1915,9 @@ long video_ioctl2(struct file *file,
> p->error_idx = p->count;
> user_ptr = (void __user *)p->controls;
> if (p->count) {
> + err = -EINVAL;
> + if (p->count > ULONG_MAX / sizeof(struct v4l2_ext_control))
> + goto out_ext_ctrl;
> ctrls_size = sizeof(struct v4l2_ext_control) * p->count;
> /* Note: v4l2_ext_controls fits in sbuf[] so mbuf is still NULL. */
> mbuf = kmalloc(ctrls_size, GFP_KERNEL);
next prev parent reply other threads:[~2011-12-15 9:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 6:34 [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in Dan Carpenter
2011-12-15 9:21 ` Mauro Carvalho Chehab [this message]
2011-12-15 9:33 ` [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy() Hans Verkuil
2011-12-15 9:50 ` Mauro Carvalho Chehab
2012-01-03 20:55 ` [patch -longterm] V4L/DVB: v4l2-ioctl: integer overflow in Greg KH
2012-01-04 13:35 ` Dan Carpenter
2012-01-05 6:27 ` [patch -next] " Dan Carpenter
2012-01-05 6:28 ` [patch -longterm v2] " Dan Carpenter
2012-01-05 16:43 ` Greg KH
2012-01-05 17:56 ` Dan Carpenter
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=4EE9BC25.7020303@infradead.org \
--to=mchehab@infradead.org \
--cc=dan.carpenter@oracle.com \
--cc=hverkuil@xs4all.nl \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=stable@vger.kernel.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