According to upstream thread (https://lkml.org/lkml/2018/5/28/2056) , cve-2017-5669 needs to address the "new" way of handling nil addresses for shmat() when used with MAP_FIXED or SHM_REMAP flags.
- mapping nil-page is OK on lower addresses with MAP_FIXED (or else X11 is broken)
- mapping nil-page is NOT OK with SHM_REMAP on lower addresses
The (Linux-specific) SHM_REMAP flag may be specified in shmflg to indicate that the mapping of the segment should replace any existing mapping in the range starting at shmaddr and continuing for the size of the segment. (Normally an EINVAL error would result if a mapping already exists in this address range.) In this case, shmaddr must not be NULL.
Based on original discussion: https://marc.info/?i=20180430172152.nfa564pvgpk3ut7p%40linux-n805
You will find initial motivation for the patches:
>> We saw that a LTP test [1] was added some time ago to reproduce behavior
>> matching that of the original report [2]. However, Andrea and I are a
>> little confused about that original report and what the upstream commit
>> was intended to fix. A quick summary of our offlist discussion:
>>
>> - This is only about privileged users (and no SELinux).
>>
>> - We modified the 20170119_shmat_nullpage_poc.c reproducer from [2] to
>> include MAP_FIXED to prove (as root, no SELinux):
>>
>> It is possible to mmap 0
>> It is NOT possible to mmap 1
>>
>> - Andrea points out that mmap(1, ...) fails not because of any
>> mmap_min_addr checks, but for alignment reasons.
>>
>> - He also wonders about other bogus addr values above 4k, but below
>> mmap_min_addr and whether this change misses those values
AND
In 4.17-rc7 you will find:
commit 8f89c007b6de
Author: Davidlohr Bueso <dave@stgolabs.net>
Date: Fri May 25 14:47:30 2018 -0700
ipc/shm: fix shmat() nil address after round-down when remapping
shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
fact the very first thing we check for. Andrea reported that for
SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
but we need to check again if the address was rounded down to nil. As
of this patch, such cases will return -EINVAL.
Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
TODO: Make sure a call to shmat() with SHM_RND & SHM_REMAP flags can't succeed for nil addresses (-EINVAL has to be returned), changing the current test that only tests SHM_RND flag.
and
commit a73ab244f0da
Author: Davidlohr Bueso <dave@stgolabs.net>
Date: Fri May 25 14:47:27 2018 -0700
Revert "ipc/shm: Fix shmat mmap nil-page protection"
Patch series "ipc/shm: shmat() fixes around nil-page".
These patches fix two issues reported[1] a while back by Joe and Andrea
around how shmat(2) behaves with nil-page.
The first reverts a commit that it was incorrectly thought that mapping
nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
with the exception of SHM_REMAP; which is address in the second patch.
I chose two patches because it is easier to backport and it explicitly
reverts bogus behaviour. Both patches ought to be in -stable and ltp
testcases need updated (the added testcase around the cve can be
modified to just test for SHM_RND|SHM_REMAP).
[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
This patch (of 2):
Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
worked on the idea that we should not be mapping as root addr=0 and
MAP_FIXED. However, it was reported that this scenario is in fact
valid, thus making the patch both bogus and breaks userspace as well.
For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
initialization[1].
[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux
Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit 95e91b831f87
Author: Davidlohr Bueso <dave@stgolabs.net>
Date: Mon Feb 27 14:28:24 2017 -0800
ipc/shm: Fix shmat mmap nil-page protection
The issue is described here, with a nice testcase:
https://bugzilla.kernel.org/show_bug.cgi?id=192931
The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
the address rounded down to 0. For the regular mmap case, the
protection mentioned above is that the kernel gets to generate the
address -- arch_get_unmapped_area() will always check for MAP_FIXED and
return that address. So by the time we do security_mmap_addr(0) things
get funky for shmat().
The testcase itself shows that while a regular user crashes, root will
not have a problem attaching a nil-page. There are two possible fixes
to this. The first, and which this patch does, is to simply allow root
to crash as well -- this is also regular mmap behavior, ie when hacking
up the testcase and adding mmap(... |MAP_FIXED). While this approach
is the safer option, the second alternative is to ignore SHM_RND if the
rounded address is 0, thus only having MAP_SHARED flags. This makes the
behavior of shmat() identical to the mmap() case. The downside of this
is obviously user visible, but does make sense in that it maintains
semantics after the round-down wrt 0 address and mmap.
Passes shm related ltp tests.
Link: http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-dave@stgolabs.net
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Reported-by: Gareth Evans <gareth.evans@contextis.co.uk>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
According to upstream thread (https://lkml.org/lkml/2018/5/28/2056) , cve-2017-5669 needs to address the "new" way of handling nil addresses for shmat() when used with MAP_FIXED or SHM_REMAP flags.
Based on original discussion: https://marc.info/?i=20180430172152.nfa564pvgpk3ut7p%40linux-n805
You will find initial motivation for the patches:
AND
In 4.17-rc7 you will find:
TODO: Make sure a call to shmat() with SHM_RND & SHM_REMAP flags can't succeed for nil addresses (-EINVAL has to be returned), changing the current test that only tests SHM_RND flag.
and