Stop container objects from claiming their children's addresses - #730
Stop container objects from claiming their children's addresses#730zardus wants to merge 1 commit into
Conversation
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Rebased onto master to resolve a conflict with #735, which rewrote Validation record for head
One test changed substantively in the rebase. #735 made the rebase search start above the main object, so a container mapped at 0 now falls below the search range in the ordinary case, and The defect first showed up in a corpus sweep, on three CaRT containers holding crash dumps in minidump format (sha256 Caveats: the fix is in |
|
Corpus decompilation diffs can be found at angr/dec-snapshots@master...angr/cle_730 |
1f3dd06 to
1288a51
Compare
An outer object holds the objects it unpacks and backs no memory, so Backend.min_addr and Backend.max_addr both report the base it was placed at: a one-byte span. _map_object inserts it into all_objects anyway, and _is_range_free counted it, so a position-dependent child linked at that same address was refused for overlapping its own container. A CaRT file keeps its linked base of 0 and blocks a child linked at 0; StaticArchive and Universal2 are position independent and land on 0x400000, which is where a non-PIE x86-64 member is linked. find_object_containing already excludes outer objects; placement now does too, in _is_range_free and in _free_gaps, where the same byte was moving the address the loader picks for the objects it rebases and laying a wrapped binary out differently from the same binary unwrapped. The same raise covered three unrelated conditions and described only the last one, so an object that simply did not fit in the architecture's address space was reported as an overlap. Split the conditions apart in _describe_range_conflict and append the reason to the message. Name the object by binary_basename, and give the object a CaRT file unpacks the wrapper's unpacked_name, so an object loaded from a stream is no longer reported as "None". Every case is covered from a fixture that is already in angr/binaries. tests/x86_64/1after909.cart is a real container: loading its contents at 0 with the blob backend reproduces the refusal exactly as the wrapped crash dumps that first showed it do. Since _free_gaps searches upward from the main object, the placement case loads the image high, which puts the free space, and so the container's byte, below it; the wrapped binary then rebases a granule away from where the unwrapped one does. The address-space case loads tests/i386/manysum as a blob near the top of the 32-bit space. No test writes a container of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1288a51 to
b680cde
Compare
2 participants
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
A binary that loads on its own fails inside a container backend when it is linked at the address the container was placed at:
Position-DEPENDENT object None cannot be loaded at 0x0. An outer backend holds no memory, so both its bounds report the base it was mapped at, a one-byte span, and placement counted that byte against the object it unpacks.find_object_containingalready skips outer objects;_is_range_freeand_free_gapsnow do too, which also makes a wrapped binary lay out the way the unwrapped one does. That error covered three unrelated conditions, so it now names the one that applies.The regression tests load
tests/x86_64/1after909.cart, a real CaRT container: mapping its contents at 0 with the blob backend reproduces the refusal, and loading it high, wrapped and unwrapped, shows the address the loader rebases into drifting by a granule. The message about running out of address space is covered by loadingtests/i386/manysumas a blob near the top of the 32-bit space. No test packs or assembles a container of its own, and every fixture is already on angr/binaries master, so there is no companion binaries PR and this does not wait on anything.Rebased onto master after #735, which rewrote
_find_safe_rebase_addrinto the_free_gapssearch this branch also touches.Validation: #730 (comment)