Attachment 729853 Details for Bug 1039348

[patch] follow up fix2

0001-mm-mmap-do-not-blow-on-PROT_NONE-MAP_FIXED-holes-in-.patch (text/plain), 2.92 KB, created by Michal Hocko on 2017-06-22 12:15:54 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Michal Hocko

Created: 2017-06-22 12:15:54 UTC

Size: 2.92 KB

patch

obsolete

>From 5a3d0bf0a4660bad63455830225c212ef6869392 Mon Sep 17 00:00:00 2001
>From: Michal Hocko <mhocko@suse.com>
>Date: Thu, 22 Jun 2017 13:27:30 +0200
>Subject: [PATCH] mm, mmap: do not blow on PROT_NONE MAP_FIXED holes in the
> stack
>
>"mm: enlarge stack guard gap" has introduced a regression in some JVM
>environments which are trying to implement their own stack guard page.
>hey are punching a new MAP_FIXED mapping inside the existing stack
>vma:
>(gdb) bt
> #0  0xf7fd9f89 in __kernel_vsyscall ()
> #1  0xf7454508 in mmap () from /lib/libc.so.6
> #2  0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> #3  0xf7afd1be in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> #4  0xf7afedd3 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> #5  0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> #6  0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffd528, szPathToClientDir=0xffffd068 "/opt/novell/groupwise/client") at grpwisex.cpp:380
> #7  0x080497a3 in main (argc=1, argv=0xffffd524) at grpwisex.cpp:473
>
>This will confuse expandable_stack_area 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.
>
>Debugged-by: Vlastimil Babka <vbabka@suse.cz>
>Signed-off-by: Michal Hocko <mhocko@suse.com>
>---
> mm/mmap.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/mm/mmap.c b/mm/mmap.c
>index 620e1e4e3296..1e722532f6c1 100644
>--- a/mm/mmap.c
>+++ b/mm/mmap.c
>@@ -2378,7 +2378,8 @@ unsigned long expandable_stack_area(struct vm_area_struct *vma,
> 	if (!next)
> 		goto out;
> 
>-	if (next->vm_flags & VM_GROWSUP) {
>+	/* see comment in !CONFIG_STACK_GROWSUP */
>+	if ((next->vm_flags & VM_GROWSUP) || !(next->vm_flags & (VM_WRITE|VM_READ))) {
> 		guard_gap = min(guard_gap, next->vm_start - address);
> 		goto out;
> 	}
>@@ -2457,8 +2458,13 @@ unsigned long expandable_stack_area(struct vm_area_struct *vma,
> 	 * That's only ok if it's the same stack mapping
> 	 * that has gotten split or there is sufficient gap
> 	 * between mappings
>+	 *
>+	 * Please note that some application (e.g. Java) punches
>+	 * MAP_FIXED inside the stack and then PROT_NONE it
>+	 * to mimic a stack guard which will clash with our protection
>+	 * so pretend tha PROT_NONE vmas are OK
> 	 */
>-	if (prev->vm_flags & VM_GROWSDOWN) {
>+	if ((prev->vm_flags & VM_GROWSDOWN) || !(prev->vm_flags & (VM_WRITE|VM_READ))) {
> 		guard_gap = min(guard_gap, address - prev->vm_end);
> 		goto out;
> 	}
>-- 
>2.11.0
>

Actions: View | Diff

Attachments on bug 1039348: 725338 | 727600 | 727601 | 727627 | 727764 | 727765 | 729853