All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian Brauner" <christian.brauner@ubuntu.com>
To: "Jann Horn" <jannh@google.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <christian@brauner.io>,
	jannh@google.com
Cc: <devel@driverdev.osuosl.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] binder: Don't modify VMA bounds in ->mmap handler
Date: Wed, 16 Oct 2019 17:46:31 +0200	[thread overview]
Message-ID: <BXR2DIW8IZSX.16Y0Y9PLOTGTS@wittgenstein> (raw)
In-Reply-To: <20191016150119.154756-1-jannh@google.com>

On Wed Oct 16, 2019 at 5:01 PM Jann Horn wrote:
> binder_mmap() tries to prevent the creation of overly big binder mappings
> by silently truncating the size of the VMA to 4MiB. However, this violates
> the API contract of mmap(). If userspace attempts to create a large binder
> VMA, and later attempts to unmap that VMA, it will call munmap() on a range
> beyond the end of the VMA, which may have been allocated to another VMA in
> the meantime. This can lead to userspace memory corruption.
> 
> The following sequence of calls leads to a segfault without this commit:
> 
> int main(void) {
>   int binder_fd = open("/dev/binder", O_RDWR);
>   if (binder_fd == -1) err(1, "open binder");
>   void *binder_mapping = mmap(NULL, 0x800000UL, PROT_READ, MAP_SHARED,
>                               binder_fd, 0);
>   if (binder_mapping == MAP_FAILED) err(1, "mmap binder");
>   void *data_mapping = mmap(NULL, 0x400000UL, PROT_READ|PROT_WRITE,
>                             MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>   if (data_mapping == MAP_FAILED) err(1, "mmap data");
>   munmap(binder_mapping, 0x800000UL);
>   *(char*)data_mapping = 1;
>   return 0;
> }
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Jann Horn <jannh@google.com>

Hm, aerc kept crashing for me so I'm not sure whether or not prior
messages made it so sorry if this arrives multiple times.

Acked-by: Christian Brauner <christian.brauner@ubuntu.com>

WARNING: multiple messages have this Message-ID (diff)
From: "Christian Brauner" <christian.brauner@ubuntu.com>
To: "Jann Horn" <jannh@google.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <christian@brauner.io>,
	jannh@google.com
Cc: devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] binder: Don't modify VMA bounds in ->mmap handler
Date: Wed, 16 Oct 2019 17:46:31 +0200	[thread overview]
Message-ID: <BXR2DIW8IZSX.16Y0Y9PLOTGTS@wittgenstein> (raw)
In-Reply-To: <20191016150119.154756-1-jannh@google.com>

On Wed Oct 16, 2019 at 5:01 PM Jann Horn wrote:
> binder_mmap() tries to prevent the creation of overly big binder mappings
> by silently truncating the size of the VMA to 4MiB. However, this violates
> the API contract of mmap(). If userspace attempts to create a large binder
> VMA, and later attempts to unmap that VMA, it will call munmap() on a range
> beyond the end of the VMA, which may have been allocated to another VMA in
> the meantime. This can lead to userspace memory corruption.
> 
> The following sequence of calls leads to a segfault without this commit:
> 
> int main(void) {
>   int binder_fd = open("/dev/binder", O_RDWR);
>   if (binder_fd == -1) err(1, "open binder");
>   void *binder_mapping = mmap(NULL, 0x800000UL, PROT_READ, MAP_SHARED,
>                               binder_fd, 0);
>   if (binder_mapping == MAP_FAILED) err(1, "mmap binder");
>   void *data_mapping = mmap(NULL, 0x400000UL, PROT_READ|PROT_WRITE,
>                             MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>   if (data_mapping == MAP_FAILED) err(1, "mmap data");
>   munmap(binder_mapping, 0x800000UL);
>   *(char*)data_mapping = 1;
>   return 0;
> }
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Jann Horn <jannh@google.com>

Hm, aerc kept crashing for me so I'm not sure whether or not prior
messages made it so sorry if this arrives multiple times.

Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  parent reply	other threads:[~2019-10-16 15:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 15:01 [PATCH 1/2] binder: Don't modify VMA bounds in ->mmap handler Jann Horn
2019-10-16 15:01 ` Jann Horn
2019-10-16 15:01 ` [PATCH 2/2] binder: Use common definition of SZ_1K Jann Horn
2019-10-16 15:01   ` Jann Horn
2019-10-16 15:16   ` Christian Brauner
2019-10-16 15:16     ` Christian Brauner
2019-10-16 15:42 ` [PATCH 1/2] binder: Don't modify VMA bounds in ->mmap handler Todd Kjos
2019-10-16 15:42   ` Todd Kjos
2019-10-16 15:46 ` Christian Brauner [this message]
2019-10-16 15:46   ` Christian Brauner

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=BXR2DIW8IZSX.16Y0Y9PLOTGTS@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=arve@android.com \
    --cc=christian@brauner.io \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=tkjos@android.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.