linux-kernel - Questions about commit "ipc/shm: Fix shmat mmap nil-page protection"

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 25 Sep 2017 15:38:07 -0400
From:   Joe Lawrence <joe.lawrence@...hat.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     Davidlohr Bueso <dave@...olabs.net>,
        Andrea Arcangeli <aarcange@...hat.com>
Subject: Questions about commit "ipc/shm: Fix shmat mmap nil-page protection"

Hi Davidlohr,

I was looking into backporting commit 95e91b831f87 ("ipc/shm: Fix shmat
mmap nil-page protection") to a distro kernel and Andrea brought up some
interesting questions about that change.

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

Is it possible that the original report noticed that shmat allowed
attach to an address of 1, and it was assumed that somehow mmap_min_addr
protections were circumvented?  Then commit 95e91b831f87 modified the
rounding in do_shmat() so that shmat would fail on similar input (but
for apparently different reasons)?

I didn't see any discussion when looking up the original commit in the
list archives, so any explanations or pointers would be very helpful.

[1]
https://github.com/linux-test-project/ltp/blob/master/testcases/cve/cve-2017-5669.c

[2] https://bugzilla.kernel.org/show_bug.cgi?id=192931

Regards,

-- Joe