about summary refs log tree commit diff
path: root/src/signal
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2013-07-23 23:18:49 -0400
committerRich Felker <dalias@aerifal.cx>2013-07-23 23:18:49 -0400
commit70a92bc968156155dd578f7fb1d4c4e3fceb32f8 (patch)
treefdfa3575ae500b26ad668109b2db9211e90d7992 /src/signal
parenta80847d86a8865a78fdbebe7f9e2533f7a74e010 (diff)
downloadmusl-70a92bc968156155dd578f7fb1d4c4e3fceb32f8.tar.gz
musl-70a92bc968156155dd578f7fb1d4c4e3fceb32f8.tar.xz
musl-70a92bc968156155dd578f7fb1d4c4e3fceb32f8.zip
fix heap corruption bug in memalign
this bug was caught by the new footer-corruption check in realloc and
free.

if the block returned by malloc was already aligned to the desired
alignment, memalign's logic to split off the misaligned head was
incorrect; rather than writing to a point inside the allocated block,
it was overwriting the footer of the previous block on the heap with
the value 1 (length 0 plus an in-use flag).

fortunately, the impact of this bug was fairly low. (this is probably
why it was not caught sooner.) due to the way the heap works, malloc
will never return a block whose previous block is free. (doing so would
be harmful because it would increase fragmentation with no benefit.)
the footer is actually not needed for in-use blocks, except that its
in-use bit needs to remain set so that it does not get merged with
free blocks, so there was no harm in it being set to 1 instead of the
correct value.

however, there is one case where this bug could have had an impact: in
multi-threaded programs, if another thread freed the previous block
after memalign's call to malloc returned, but before memalign
overwrote the previous block's footer, the resulting block in the free
list could be left in a corrupt state. I have not analyzed the impact
of this bad state and whether it could lead to more serious
malfunction.
Diffstat (limited to 'src/signal')
0 files changed, 0 insertions, 0 deletions