*** 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.
* What exactly did you do (or not do) that was effective (or
* 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.
|Location:||Huddersfield, West Yorkshire, UK|
|Nodes:||8 (1 / 7)|