]> git.proxmox.com Git - mirror_ubuntu-zesty-kernel.git/commit
mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
authorMichal Hocko <mhocko@suse.com>
Mon, 17 Jul 2017 12:53:28 +0000 (14:53 +0200)
committerKleber Sacilotto de Souza <kleber.souza@canonical.com>
Tue, 18 Jul 2017 08:29:32 +0000 (10:29 +0200)
commit8105a5d532683a3a73d48f55f0e9bb8115001b5e
treebb49795e257bcd4e057585b71d602a2fa1df361e
parentffee953146a2823c81396f94d157c21f022a32d4
mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack

Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") has
introduced a regression in some rust and Java environments which are
trying to implement their own stack guard page.  They are punching a new
MAP_FIXED mapping inside the existing stack Vma.

This will confuse expand_{downwards,upwards} into thinking that the
stack expansion would in fact get us too close to an existing non-stack
vma which is a correct behavior wrt safety.  It is a real regression on
the other hand.

Let's work around the problem by considering PROT_NONE mapping as a part
of the stack.  This is a gros hack but overflowing to such a mapping
would trap anyway an we only can hope that usespace knows what it is
doing and handle it propely.

Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas")
Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko@suse.com>
Debugged-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CVE-2017-1000364

(cherry picked from commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f)
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
mm/mmap.c