Bug#866686: libc6: The stack clash fix is insufficient, because it doesn't increase the stack guard gap for thread stacks
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
aurelien@aurel32.net http://www.aurel32.net
Reply to: