On 2017-06-30 23:56, Mikulas Patocka wrote: > Package: libc6 > Severity: important > Tags: upstream > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > * What led up to the situation? > > The stack clash patch modifies the kernel so that there is 1MB gap below the > stack. If a single function allocates 1MB or less space on its stack frame, it > would hit the gap and it couldn't overwrite heap. > > However, the stack gap for thread stacks is still 4k, meaning that the whole > stack clash exploit could be still used against multithreaded programs.
The guard size for threads can be changed by calling the pthread_attr_setguardsize function before the thread creation. POSIX clearly defines the default thread guard size to be PAGESIZE: "The default value of the guardsize attribute is PAGESIZE bytes. The actual value of PAGESIZE is implementation-dependent and may not be the same on all implementations." > * What exactly did you do (or not do) that was effective (or > ineffective)? > * What was the outcome of this action? > > Run pmap on any multithreaded process and you can see that there is only 4k > gap > below the thread stack, for example: > 00007f931d83d000 4K ----- [ anon ] > 00007f931d83e000 8192K rw--- [ anon ] > 00007f931e03e000 4K ----- [ anon ] > 00007f931e03f000 8192K rw--- [ anon ] > 00007f931e83f000 4K ----- [ anon ] > 00007f931e840000 8192K rw--- [ anon ] > 00007f931f040000 4K ----- [ anon ] > 00007f931f041000 8192K rw--- [ anon ] > 00007f931f841000 4K ----- [ anon ] > 00007f931f842000 8192K rw--- [ anon ] > > * What outcome did you expect instead? > The libc should be modified so that there is 1MB guard area below the thread > stack. > I am not sure we should violate POSIX there. This probably has to be discussed with upstream first. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net