All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Jann Horn <jannh@google.com>, Michal Hocko <mhocko@suse.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	<abdhalee@linux.vnet.ibm.com>, <joel@jms.id.au>,
	Kees Cook <keescook@chromium.org>, <jasone@google.com>,
	<davidtgoldblatt@gmail.com>, <trasz@freebsd.org>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Daniel Micay <danielmicay@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE
Date: Wed, 10 Oct 2018 11:17:18 -0700	[thread overview]
Message-ID: <419ee581-ad6b-9a1d-ccea-ae63163926d1@nvidia.com> (raw)
In-Reply-To: <CAG48ez04KK62doMwsTVN4nN8y_wmv7hn+4my2jk5VXKL0wP7Lg@mail.gmail.com>

On 10/10/18 10:26 AM, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko <mhocko@suse.com> wrote:
>> On Wed 10-10-18 17:27:36, Jann Horn wrote:
>>> Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
>>> application causes that application to randomly crash. The existing check
>>> for handling MAP_FIXED_NOREPLACE looks up the first VMA that either
>>> overlaps or follows the requested region, and then bails out if that VMA
>>> overlaps *the start* of the requested region. It does not bail out if the
>>> VMA only overlaps another part of the requested region.
>>
>> I do not understand. Could you give me an example?
> 
> Sure.
> 
> =======
> user@debian:~$ cat mmap_fixed_simple.c
> #include <sys/mman.h>
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> 
> #ifndef MAP_FIXED_NOREPLACE
> #define MAP_FIXED_NOREPLACE 0x100000
> #endif
> 
> int main(void) {
>   char *p;
> 
>   errno = 0;
>   p = mmap((void*)0x10001000, 0x4000, PROT_NONE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
>   printf("p1=%p err=%m\n", p);
> 
>   errno = 0;
>   p = mmap((void*)0x10000000, 0x2000, PROT_READ,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
>   printf("p2=%p err=%m\n", p);
> 
>   char cmd[100];
>   sprintf(cmd, "cat /proc/%d/maps", getpid());
>   system(cmd);
> 
>   return 0;
> }
> user@debian:~$ gcc -o mmap_fixed_simple mmap_fixed_simple.c
> user@debian:~$ ./mmap_fixed_simple
> p1=0x10001000 err=Success
> p2=0x10000000 err=Success
> 10000000-10002000 r--p 00000000 00:00 0
> 10002000-10005000 ---p 00000000 00:00 0
> 564a9a06f000-564a9a070000 r-xp 00000000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a26f000-564a9a270000 r--p 00000000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a270000-564a9a271000 rw-p 00001000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a54a000-564a9a56b000 rw-p 00000000 00:00 0                          [heap]
> 7f8eba447000-7f8eba5dc000 r-xp 00000000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba5dc000-7f8eba7dc000 ---p 00195000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7dc000-7f8eba7e0000 r--p 00195000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7e0000-7f8eba7e2000 rw-p 00199000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7e2000-7f8eba7e6000 rw-p 00000000 00:00 0
> 7f8eba7e6000-7f8eba809000 r-xp 00000000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8eba9e9000-7f8eba9eb000 rw-p 00000000 00:00 0
> 7f8ebaa06000-7f8ebaa09000 rw-p 00000000 00:00 0
> 7f8ebaa09000-7f8ebaa0a000 r--p 00023000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8ebaa0a000-7f8ebaa0b000 rw-p 00024000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8ebaa0b000-7f8ebaa0c000 rw-p 00000000 00:00 0
> 7ffcc99fa000-7ffcc9a1b000 rw-p 00000000 00:00 0                          [stack]
> 7ffcc9b44000-7ffcc9b47000 r--p 00000000 00:00 0                          [vvar]
> 7ffcc9b47000-7ffcc9b49000 r-xp 00000000 00:00 0                          [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
>   [vsyscall]
> user@debian:~$ uname -a
> Linux debian 4.19.0-rc6+ #181 SMP Wed Oct 3 23:43:42 CEST 2018 x86_64 GNU/Linux
> user@debian:~$
> =======
> 
> As you can see, the first page of the mapping at 0x10001000 was clobbered.

This looks good to me. The short example really helped, thanks for that.

(I think my first reply got bounced, sorry if this ends up as a duplicate email
for anyone.)

thanks,
-- 
John Hubbard
NVIDIA

WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Jann Horn <jannh@google.com>, Michal Hocko <mhocko@suse.com>
Cc: Linux-MM <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	abdhalee@linux.vnet.ibm.com, joel@jms.id.au,
	Kees Cook <keescook@chromium.org>,
	jasone@google.com, davidtgoldblatt@gmail.com, trasz@freebsd.org,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Daniel Micay <danielmicay@gmail.com>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE
Date: Wed, 10 Oct 2018 11:17:18 -0700	[thread overview]
Message-ID: <419ee581-ad6b-9a1d-ccea-ae63163926d1@nvidia.com> (raw)
In-Reply-To: <CAG48ez04KK62doMwsTVN4nN8y_wmv7hn+4my2jk5VXKL0wP7Lg@mail.gmail.com>

On 10/10/18 10:26 AM, Jann Horn wrote:
> On Wed, Oct 10, 2018 at 7:19 PM Michal Hocko <mhocko@suse.com> wrote:
>> On Wed 10-10-18 17:27:36, Jann Horn wrote:
>>> Daniel Micay reports that attempting to use MAP_FIXED_NOREPLACE in an
>>> application causes that application to randomly crash. The existing check
>>> for handling MAP_FIXED_NOREPLACE looks up the first VMA that either
>>> overlaps or follows the requested region, and then bails out if that VMA
>>> overlaps *the start* of the requested region. It does not bail out if the
>>> VMA only overlaps another part of the requested region.
>>
>> I do not understand. Could you give me an example?
> 
> Sure.
> 
> =======
> user@debian:~$ cat mmap_fixed_simple.c
> #include <sys/mman.h>
> #include <errno.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> 
> #ifndef MAP_FIXED_NOREPLACE
> #define MAP_FIXED_NOREPLACE 0x100000
> #endif
> 
> int main(void) {
>   char *p;
> 
>   errno = 0;
>   p = mmap((void*)0x10001000, 0x4000, PROT_NONE,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
>   printf("p1=%p err=%m\n", p);
> 
>   errno = 0;
>   p = mmap((void*)0x10000000, 0x2000, PROT_READ,
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED_NOREPLACE, -1, 0);
>   printf("p2=%p err=%m\n", p);
> 
>   char cmd[100];
>   sprintf(cmd, "cat /proc/%d/maps", getpid());
>   system(cmd);
> 
>   return 0;
> }
> user@debian:~$ gcc -o mmap_fixed_simple mmap_fixed_simple.c
> user@debian:~$ ./mmap_fixed_simple
> p1=0x10001000 err=Success
> p2=0x10000000 err=Success
> 10000000-10002000 r--p 00000000 00:00 0
> 10002000-10005000 ---p 00000000 00:00 0
> 564a9a06f000-564a9a070000 r-xp 00000000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a26f000-564a9a270000 r--p 00000000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a270000-564a9a271000 rw-p 00001000 fe:01 264004
>   /home/user/mmap_fixed_simple
> 564a9a54a000-564a9a56b000 rw-p 00000000 00:00 0                          [heap]
> 7f8eba447000-7f8eba5dc000 r-xp 00000000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba5dc000-7f8eba7dc000 ---p 00195000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7dc000-7f8eba7e0000 r--p 00195000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7e0000-7f8eba7e2000 rw-p 00199000 fe:01 405885
>   /lib/x86_64-linux-gnu/libc-2.24.so
> 7f8eba7e2000-7f8eba7e6000 rw-p 00000000 00:00 0
> 7f8eba7e6000-7f8eba809000 r-xp 00000000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8eba9e9000-7f8eba9eb000 rw-p 00000000 00:00 0
> 7f8ebaa06000-7f8ebaa09000 rw-p 00000000 00:00 0
> 7f8ebaa09000-7f8ebaa0a000 r--p 00023000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8ebaa0a000-7f8ebaa0b000 rw-p 00024000 fe:01 405876
>   /lib/x86_64-linux-gnu/ld-2.24.so
> 7f8ebaa0b000-7f8ebaa0c000 rw-p 00000000 00:00 0
> 7ffcc99fa000-7ffcc9a1b000 rw-p 00000000 00:00 0                          [stack]
> 7ffcc9b44000-7ffcc9b47000 r--p 00000000 00:00 0                          [vvar]
> 7ffcc9b47000-7ffcc9b49000 r-xp 00000000 00:00 0                          [vdso]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
>   [vsyscall]
> user@debian:~$ uname -a
> Linux debian 4.19.0-rc6+ #181 SMP Wed Oct 3 23:43:42 CEST 2018 x86_64 GNU/Linux
> user@debian:~$
> =======
> 
> As you can see, the first page of the mapping at 0x10001000 was clobbered.

This looks good to me. The short example really helped, thanks for that.

(I think my first reply got bounced, sorry if this ends up as a duplicate email
for anyone.)

thanks,
-- 
John Hubbard
NVIDIA

  parent reply	other threads:[~2018-10-10 18:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 15:27 [PATCH] mm: don't clobber partially overlapping VMA with MAP_FIXED_NOREPLACE Jann Horn
2018-10-10 17:19 ` Michal Hocko
2018-10-10 17:26   ` Jann Horn
2018-10-10 17:38     ` Michal Hocko
2018-10-10 18:03       ` John Hubbard
2018-10-10 18:03         ` John Hubbard
2018-10-10 18:17     ` John Hubbard [this message]
2018-10-10 18:17       ` John Hubbard
2018-10-12 10:23     ` Michael Ellerman
2018-10-12 12:09       ` Jann Horn
2018-10-10 18:36 ` Kees Cook
2018-10-12 12:03 ` Vlastimil Babka
2018-10-15  7:47 ` Khalid Aziz

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=419ee581-ad6b-9a1d-ccea-ae63163926d1@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=abdhalee@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=danielmicay@gmail.com \
    --cc=davidtgoldblatt@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=jannh@google.com \
    --cc=jasone@google.com \
    --cc=joel@jms.id.au \
    --cc=keescook@chromium.org \
    --cc=khalid.aziz@oracle.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@armlinux.org.uk \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=trasz@freebsd.org \
    --cc=willy@infradead.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 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.