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 /src/complex/carg.c | |
parent | bd1eaceaa3975bd2a2a34e211cff896affaecadf (diff) | |
download | musl-276904c2f6bde3a31a24ebfa201482601d18b4f9.tar.gz musl-276904c2f6bde3a31a24ebfa201482601d18b4f9.tar.bz2 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 'src/complex/carg.c')
0 files changed, 0 insertions, 0 deletions