The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.
Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Arve Hjønnevåg <[email protected]>
Cc: Todd Kjos <[email protected]>
Cc: Martijn Coenen <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Alistair Strachan <[email protected]>
---
drivers/staging/android/ashmem.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index a1a0025b59e0..1eeedb529a10 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -366,6 +366,12 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
goto out;
}
+ /* requested mapping size larger than object size */
+ if (unlikely(vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size))) {
+ ret = -EINVAL;
+ goto out;
+ }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask, 0)) &
calc_vm_prot_bits(PROT_MASK, 0))) {
On Tue, Jun 19, 2018 at 03:24:44PM -0700, Alistair Strachan wrote:
> The ashmem driver did not check that the size/offset of the vma passed
> to its .mmap() function was not larger than the ashmem object being
> mapped. This could cause mmap() to succeed, even though accessing parts
> of the mapping would later fail with a segmentation fault.
>
> Ensure an error is returned by the ashmem_mmap() function if the vma
> size is larger than the ashmem object size. This enables safer handling
> of the problem in userspace.
Is this going to break current users of this api as their original call
was succeeding?
>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Arve Hj?nnev?g <[email protected]>
> Cc: Todd Kjos <[email protected]>
> Cc: Martijn Coenen <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Alistair Strachan <[email protected]>
> ---
> drivers/staging/android/ashmem.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
> index a1a0025b59e0..1eeedb529a10 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -366,6 +366,12 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> goto out;
> }
>
> + /* requested mapping size larger than object size */
> + if (unlikely(vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size))) {
> + ret = -EINVAL;
> + goto out;
> + }
Unless you can measure the speed difference, never use likely/unlikely.
The CPU and compiler almost always knows how to do this better than we
do. I know there are other checks like this in this function, those
should also be fixed as well.
thanks,
greg k-h
HI Greg,
On Tue, Jun 19, 2018 at 4:01 PM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Tue, Jun 19, 2018 at 03:24:44PM -0700, Alistair Strachan wrote:
> > The ashmem driver did not check that the size/offset of the vma passed
> > to its .mmap() function was not larger than the ashmem object being
> > mapped. This could cause mmap() to succeed, even though accessing parts
> > of the mapping would later fail with a segmentation fault.
> >
> > Ensure an error is returned by the ashmem_mmap() function if the vma
> > size is larger than the ashmem object size. This enables safer handling
> > of the problem in userspace.
>
> Is this going to break current users of this api as their original call
> was succeeding?
If the user created an ashmem region, set its size with
ASHMEM_SET_SIZE, then mmap()ed a larger size, but did not touch the
extra memory it just tried to mmap(), it could pass with the existing
driver. With this patch, it would fail at mmap() time. We're not aware
of users that rely on such behavior.
> >
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: Arve Hjønnevåg <[email protected]>
> > Cc: Todd Kjos <[email protected]>
> > Cc: Martijn Coenen <[email protected]>
> > Cc: [email protected]
> > Cc: [email protected]
> > Signed-off-by: Alistair Strachan <[email protected]>
> > ---
> > drivers/staging/android/ashmem.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
> > index a1a0025b59e0..1eeedb529a10 100644
> > --- a/drivers/staging/android/ashmem.c
> > +++ b/drivers/staging/android/ashmem.c
> > @@ -366,6 +366,12 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> > goto out;
> > }
> >
> > + /* requested mapping size larger than object size */
> > + if (unlikely(vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size))) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
>
> Unless you can measure the speed difference, never use likely/unlikely.
> The CPU and compiler almost always knows how to do this better than we
> do. I know there are other checks like this in this function, those
> should also be fixed as well.
Sure. I'll split that out into another change and resend.
>
> thanks,
>
> greg k-h