diff options
author | Rich Felker <dalias@aerifal.cx> | 2013-07-23 23:18:49 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2013-07-23 23:18:49 -0400 |
commit | 70a92bc968156155dd578f7fb1d4c4e3fceb32f8 (patch) | |
tree | fdfa3575ae500b26ad668109b2db9211e90d7992 /Makefile | |
parent | a80847d86a8865a78fdbebe7f9e2533f7a74e010 (diff) | |
download | musl-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 'Makefile')
0 files changed, 0 insertions, 0 deletions