fix malloc state corruption when ldso rejects loading a second libc
authorRich Felker <dalias@aerifal.cx>
Mon, 13 Nov 2017 20:27:10 +0000 (15:27 -0500)
committerRich Felker <dalias@aerifal.cx>
Mon, 13 Nov 2017 20:27:10 +0000 (15:27 -0500)
commita71b46cfd289aa0ff829fc9a436c59c398f8326d
treed830e2f59a7d4dd89aad7288224597b80af5677e
parentd060edf6c569ba9df4b52d6bcd93edde812869c9
fix malloc state corruption when ldso rejects loading a second libc

commit c49d3c8adadfa24235fcf4779bb722b1aa6f480b added logic to detect
attempts to load libc.so via another name and instead redirect to the
existing libc, rather than loading two and producing dangerously
inconsistent state. however, the check for and unmapping of the
duplicate libc happened after reclaim_gaps was already called,
donating the slack space around the writable segment to malloc.
subsequent unmapping of the library then invalidated malloc's free
lists.

fix the issue by moving the call to reclaim_gaps out of map_library
into load_library, after the duplicate libc check but before the first
call to calloc, so that the gaps can still be used to satisfy the
allocation of struct dso. this change also eliminates the need for an
ugly hack (temporarily setting runtime=1) to avoid reclaim_gaps when
loading the main program via map_library, which happens when ldso is
invoked as a command.

only programs/libraries erroneously containing a DT_NEEDED reference
to libc.so via an absolute pathname or symlink were affected by this
issue.
ldso/dynlink.c