Fix collision detection for resized PHTs - #644
Closed
godlygeek wants to merge 2 commits into
Closed
Conversation
godlygeek
force-pushed
the
fix_pht_collision_detection
branch
from
June 17, 2026 19:20
5023ffc to
cfc7c2d
Compare
Add a regression test to ensure that PHT collision detection correctly detects when growing the PHT in place would cause it to collide with another section, even if the PHT is not at the start of the ELF file.
Patching a shared library might require extending its program header table, which can then cause it to run out of its originally allocated space. After 484d349, patchelf handles this by detecting that growing the PHT in place would result in a collision with a section that won't be moved, in which case it instead moves the PHT to the end of the ELF file. The logic checking for collisions incorrectly assumes that the PHT is originally at the start of the file, though. It checks every section after the first to see if it overlaps with the PHT given its new size, but it assumes that the PHT's original position is immediately after the ELF header, `sizeof(Elf_Ehdr)` bytes into the file. In other words, it's currently looking for collisions in the range: [0, roundUp(sizeof(Elf_Ehdr) + newPhtSize, sectionAlignment)] This commit fixes it to check for collisions in the correct range: [hdr()->e_phoff, hdr()->e_phoff + roundUp(newPhtSize, sectionAlignment)]
godlygeek
force-pushed
the
fix_pht_collision_detection
branch
from
June 17, 2026 19:30
cfc7c2d to
6cd7c9a
Compare
Contributor
Author
|
It was surprisingly difficult to write a regression test for this. I'd be open to doing it a different way - either vendoring a |
Member
|
Fixed in #652 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Patching a shared library might require extending its program header
table, which can then cause it to run out of its originally allocated
space. After 484d349, patchelf handles this by detecting that growing
the PHT in place would result in a collision with a section that won't
be moved, in which case it instead moves the PHT to the end of the ELF
file.
The logic checking for collisions incorrectly assumes that the PHT is
originally at the start of the file, though. It checks every section
after the first to see if it overlaps with the PHT given its new size,
but it assumes that the PHT's original position is immediately after the
ELF header,
sizeof(Elf_Ehdr)bytes into the file.In other words, it's currently looking for collisions in the range:
This commit fixes it to check for collisions in the correct range:
Closes #643