public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: "Hiremath, Vaibhav" <hvaibhav@ti.com>
Cc: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"mchehab@redhat.com" <mchehab@redhat.com>,
	"hverkuil@xs4all.nl" <hverkuil@xs4all.nl>
Subject: Re: [PATCH] omap_vout: Added check in reqbuf & mmap for buf_size allocation
Date: Fri, 17 Jun 2011 14:15:57 +0530	[thread overview]
Message-ID: <4DFB1445.3000102@ti.com> (raw)
In-Reply-To: <1308255249-18762-1-git-send-email-hvaibhav@ti.com>

Hi,

On Friday 17 June 2011 01:44 AM, Hiremath, Vaibhav wrote:
> From: Vaibhav Hiremath<hvaibhav@ti.com>
>
> The usecase where, user allocates small size of buffer
> through bootargs (video1_bufsize/video2_bufsize) and later from application
> tries to set the format which requires larger buffer size, driver doesn't
> check for insufficient buffer size and allows application to map extra buffer.
> This leads to kernel crash, when user application tries to access memory
> beyond the allocation size.

Query: Why do we pass the bufsize as bootargs in the first place? Is it 
needed at probe time?

Thanks,
Archit

>
> Added check in both mmap and reqbuf call back function,
> and return error if the size of the buffer allocated by user through
> bootargs is less than the S_FMT size.
>
> Signed-off-by: Vaibhav Hiremath<hvaibhav@ti.com>
> ---
>   drivers/media/video/omap/omap_vout.c |   16 ++++++++++++++++
>   1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c
> index 3bc909a..343b50c 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -678,6 +678,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count,
>   	startindex = (vout->vid == OMAP_VIDEO1) ?
>   		video1_numbuffers : video2_numbuffers;
>
> +	/* Check the size of the buffer */
> +	if (*size>  vout->buffer_size) {
> +		v4l2_err(&vout->vid_dev->v4l2_dev,
> +				"buffer allocation mismatch [%u] [%u]\n",
> +				*size, vout->buffer_size);
> +		return -ENOMEM;
> +	}
> +
>   	for (i = startindex; i<  *count; i++) {
>   		vout->buffer_size = *size;
>
> @@ -856,6 +864,14 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma)
>   				(vma->vm_pgoff<<  PAGE_SHIFT));
>   		return -EINVAL;
>   	}
> +	/* Check the size of the buffer */
> +	if (size>  vout->buffer_size) {
> +		v4l2_err(&vout->vid_dev->v4l2_dev,
> +				"insufficient memory [%lu] [%u]\n",
> +				size, vout->buffer_size);
> +		return -ENOMEM;
> +	}
> +
>   	q->bufs[i]->baddr = vma->vm_start;
>
>   	vma->vm_flags |= VM_RESERVED;
> --
> 1.6.2.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2011-06-17  8:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 20:14 [PATCH] omap_vout: Added check in reqbuf & mmap for buf_size allocation hvaibhav
2011-06-17  8:45 ` Archit Taneja [this message]
2011-06-17 10:03   ` Hiremath, Vaibhav
2011-06-17 10:27     ` Archit Taneja
2011-06-17 10:23       ` Hiremath, Vaibhav
2011-06-17 10:49         ` Archit Taneja

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=4DFB1445.3000102@ti.com \
    --to=archit@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.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