From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227tT6hoEzgj5HaFLc9L6ypziB4EaaA2mVFebRBMAZ39VLLB00nWU7fdhdPKNuIpDj4/EGe9 ARC-Seal: i=1; a=rsa-sha256; t=1517256712; cv=none; d=google.com; s=arc-20160816; b=y+s+FQBFHZwjnGQIl5EUyCCaqL+dQA/hOm4FbDP98Luvc5f8FlKGPeOkx/1ra1Ho9S NlVDpbV/z9tn6v92J6HzNgLIPGuDYEucaQ9wzIt8ZMA/KuYytS1NVsvosdf+SiKIU8r2 nTG+IISJ3AeG4gLzNx0NYqdo4lhqWXpAfrflSyqFMA+wy1Cw2U2cHTpeVGG9U/Jnnywf 2PUq4zb+4JgU3PGpk8P04BohDdIPs7AWnS+fQXRWqVHSWdDVL1c3kXV/Qoh9ALoK0TP7 /+/MM916H9pSUjJpvfSIh7Q/XvNut/gX//YNjr4KhfCGScPQap9EBawZP9j6pUT/lIAs csSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=PcC9sPCPupEE/M92Dnazi8vOvI9pC5CS/ojSBJ/bY1A=; b=sw+kR3G29syqZg6BvaSPOqe4W8wRpe3gkx7QZV4xbxtJJHQq2HYuv7T5W6OrI34HWV plmOahszU4y8QNVDn2F2FKq3DD6cPrMl9EX98YN6eOJYeldOXqMr2xKNa3S8B3cKASyz 9dQQj8exzpQloL0L/JyAbKw6iuYZ3BxKGsafwqsVgusYu62eWkDWVfv3lwssGEHw2+Vv 5PAjELokZmVDC2eefYAIdNWJ1QHkxGoZCSw38Nggqcwq4swXPRhoBRzRaYVKNpccr9R6 ieeCXRTLWEELibq3bitrtr6psjiKVJSs0qpQVIK8qfTAeY0knVtdQSWUyXQIQaQaBnWU lD1w== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.71.90 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning gregkh@linuxfoundation.org does not designate 90.92.71.90 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michal Hocko , Ben Hutchings , Willy Tarreau , Oleg Nesterov , Rik van Riel , Hugh Dickins , Andrew Morton , Linus Torvalds Subject: [PATCH 3.18 24/52] mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack Date: Mon, 29 Jan 2018 13:56:42 +0100 Message-Id: <20180129123629.251082861@linuxfoundation.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180129123628.168904217@linuxfoundation.org> References: <20180129123628.168904217@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcU2VudCI=?= X-GMAIL-THRID: =?utf-8?q?1590958973747128688?= X-GMAIL-MSGID: =?utf-8?q?1590958973747128688?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Michal Hocko commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f upstream. 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 Debugged-by: Vlastimil Babka Cc: Ben Hutchings Cc: Willy Tarreau Cc: Oleg Nesterov Cc: Rik van Riel Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/mmap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2191,7 +2191,8 @@ int expand_upwards(struct vm_area_struct gap_addr = TASK_SIZE; next = vma->vm_next; - if (next && next->vm_start < gap_addr) { + if (next && next->vm_start < gap_addr && + (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { if (!(next->vm_flags & VM_GROWSUP)) return -ENOMEM; /* Check that both stack segments have the same anon_vma? */ @@ -2271,7 +2272,8 @@ int expand_downwards(struct vm_area_stru if (gap_addr > address) return -ENOMEM; prev = vma->vm_prev; - if (prev && prev->vm_end > gap_addr) { + if (prev && prev->vm_end > gap_addr && + (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) { if (!(prev->vm_flags & VM_GROWSDOWN)) return -ENOMEM; /* Check that both stack segments have the same anon_vma? */