When a section in the file needs to be enlarged (e.g. to accommodate
setting a larger RPATH), shiftFile() is used to shift all content
following the growing section to a later position in the file.
Commit 109b771 introduced logic to
ensure that, after the segment split, no sections span multiple
segments. This is done by sliding the portion of the segment after the
split point later in the file, then adding a new PT_LOAD segment that
contains the preceding data plus the extra room that is being added. The
existing implementation does this by simply adding
`extraPages*getPageSize()` bytes to the number of bytes ahead of the
split point in the segment.
However, this approach can result in two PT_LOAD segments that overlap
when page boundaries are taken into account. As an example, this PT_LOAD
section (taken from a Python 3.10 binary):
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x0000000000000948 0x0000000000000948 R E 0x200000
is split into the following two sections:
LOAD 0x0000000000000000 0x00000000003ff000 0x00000000003ff000
0x0000000000001594 0x0000000000001594 R E 0x1000
LOAD 0x0000000000001594 0x0000000000400594 0x0000000000400594
0x00000000000003b4 0x00000000000003b4 R E 0x1000
Note that the two PT_LOAD sections both contain the memory page at
address 0x400000. The Linux kernel's ELF loader (at least as of v4.18)
does not accept this as a valid ELF executable, triggering a segfault
with si_code=SI_KERNEL immediately when the binary is executed.
The fix here is to set the length of the segment that comes before the
split point more carefully; instead of adding `extraPages*getPageSize()`
bytes to the portion of the segment that came before the split, the
actual number of padding bytes that were needed (before rounding up to
the next multiple of the page size) are used. This avoids the overlap
in the PT_LOAD segments and makes the output files executable again.