linux-kernel - Re: [PATCH 3.10 268/268] mm: larger stack guard gap, between vmas

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-prev] [day] [month] [year] [list]

Date:   Wed, 21 Jun 2017 18:01:01 +0200
From:   Willy Tarreau <w@....eu>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 3.10 268/268] mm: larger stack guard gap, between vmas

Hey Hugh,

On Wed, Jun 21, 2017 at 09:18:23AM +0200, Willy Tarreau wrote:
> Thanks a lot, I'll include your patch and will test it again. And
> yes, I intend to merge Helge's fix once it lands into mainline (maybe
> it is right now, I didn't check) and possibly other ones you might be
> working on depending on various feedback.

So here's a quick update, I've built a kernel with my initial backport
fixed by applying your patch on top of it and have run various tests
on it. All I can say is that for me it works. I've instrumented a
little bit more my test program (which I'm attaching).

With 3.10.106+ unpatched, I get this :

admin@...milux:~$ ulimit -s unlimited
admin@...milux:~$ /tmp/gap 65536 < /dev/null 
mmap() failed
stack=0x550024b0 [0x550024b0-0x7fc6d0f0] (717663296 total bytes)
heap~=(nil) [(nil)-(nil)] (0 total bytes)
anon~=0x7ffef000 [0x2aaab000-0x7ffef000] (1431584768 total bytes)
heap...stack=2143736048 bytes
heap+anon+stack=2149248064 bytes
08048000-080d6000 r-xp 00000000 00:0d 3263       /var/tmp/gap
080d6000-080d8000 rw-p 0008d000 00:0d 3263       /var/tmp/gap
080d8000-080fb000 rw-p 00000000 00:00 0          [heap]
2aaab000-5537d000 rw-p 00000000 00:00 0          [stack:1813]
55382000-7fc7f000 rw-p 00000000 00:00 0 
7fc7f000-7ffff000 rw-p 00000000 00:00 0 
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
rounds: 10949

The output is not obvious, it dumps its last known pointer for each
VMA and the upper and lower known as well, then dumps the contents
of /proc/self/maps either after the segfault or after a failed
alloc. Here you can see that the stack was seen equal to 0x550024b0,
which totally belongs to the anon area, which is reported as stack
in /proc/self/maps probably due to the pointers crossing each other.
The stack really was the next VMA (55382000-7fc7f000). So we had a
significant collision here, with about ~56 stack accesses being made
in the anon VMA.

With 3.10.107-rc and your latest fix I get this :

admin@...milux:~$ ulimit -s unlimited
admin@...milux:~$ /tmp/gap 65536 </dev/null  
SEGV caught
stack=0x552cb240 [0x552db250-0x7fa15960] (712222480 total bytes)
heap~=(nil) [(nil)-(nil)] (0 total bytes)
anon~=0x7fa27000 [0x2aaab000-0x7fa27000] (1425522688 total bytes)
heap...stack=2141280608 bytes
heap+anon+stack=2137745168 bytes
08048000-080d6000 r-xp 00000000 00:0d 3263       /var/tmp/gap
080d6000-080d8000 rw-p 0008d000 00:0d 3263       /var/tmp/gap
080d8000-080fb000 rw-p 00000000 00:00 0          [heap]
2aaab000-551cd000 rw-p 00000000 00:00 0 
552db000-7fa27000 rw-p 00000000 00:00 0 
7fa27000-7fa37000 rw-p 00000000 00:00 0 
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]

There's no collision, the stack access stopped on the guard page.

The program is ugly but usable. If you pass it a negative size it will
first fill the heap for this absolute size, then switch to anon. It's
useless now but who knows.

So for me it's OK now. I'm attaching the test program. Greg, Ben, Sasha,
you need a 2 GB i386 machine to reliably test it (booting in a VM is OK).
I can provide you with a small system image offline if needed.

Cheers,
Willy

View attachment "gap.c" of type "text/plain" (2443 bytes)