linux-kernel - Re: [PATCH] staging: android: ashmem: Fix mmap size validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Jun 2018 17:02:20 -0700
From:   Alistair Strachan <astrachan@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org,
        Arve Hjønnevåg <arve@...roid.com>,
        Todd Kjos <tkjos@...roid.com>,
        Martijn Coenen <maco@...roid.com>, devel@...verdev.osuosl.org,
        kernel-team@...roid.com, joel@...lfernandes.org
Subject: Re: [PATCH] staging: android: ashmem: Fix mmap size validation

HI Greg,

On Tue, Jun 19, 2018 at 4:01 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> 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 <gregkh@...uxfoundation.org>
> > Cc: Arve Hjønnevåg <arve@...roid.com>
> > Cc: Todd Kjos <tkjos@...roid.com>
> > Cc: Martijn Coenen <maco@...roid.com>
> > Cc: devel@...verdev.osuosl.org
> > Cc: kernel-team@...roid.com
> > Signed-off-by: Alistair Strachan <astrachan@...gle.com>
> > ---
> >  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