diff options
author | Rich Felker <dalias@aerifal.cx> | 2015-06-09 20:30:35 +0000 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2015-06-09 21:31:55 +0000 |
commit | 276904c2f6bde3a31a24ebfa201482601d18b4f9 (patch) | |
tree | de72437def91f8479a027d51d69d0a11fa96cfc2 /Makefile | |
parent | bd1eaceaa3975bd2a2a34e211cff896affaecadf (diff) | |
download | musl-276904c2f6bde3a31a24ebfa201482601d18b4f9.tar.gz musl-276904c2f6bde3a31a24ebfa201482601d18b4f9.tar.xz musl-276904c2f6bde3a31a24ebfa201482601d18b4f9.zip |
in malloc, refuse to use brk if it grows into stack
the linux/nommu fdpic ELF loader sets up the brk range to overlap entirely with the main thread's stack (but growing from opposite ends), so that the resulting failure mode for malloc is not to return a null pointer but to start returning pointers to memory that overlaps with the caller's stack. needless to say this extremely dangerous and makes brk unusable. since it's non-trivial to detect execution environments that might be affected by this kernel bug, and since the severity of the bug makes any sort of detection that might yield false-negatives unsafe, we instead check the proximity of the brk to the stack pointer each time the brk is to be expanded. both the main thread's stack (where the real known risk lies) and the calling thread's stack are checked. an arbitrary gap distance of 8 MB is imposed, chosen to be larger than linux default main-thread stack reservation sizes and larger than any reasonable stack configuration on nommu. the effeciveness of this patch relies on an assumption that the amount by which the brk is being grown is smaller than the gap limit, which is always true for malloc's use of brk. reliance on this assumption is why the check is being done in malloc-specific code and not in __brk.
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions