Correction to my original report: it understates the problem, because the
diagnosis I gave was incomplete.
glibc refuses such objects for two distinct reasons, and both are reported
with the same message, which is what misled me:
1. elf/dl-load.c
((ph->p_vaddr - ph->p_offset) & (GLRO(dl_pagesize) - 1)) != 0
2. elf/dl-map-segments.h
loadcmds[nloadcmds - 1].mapstart < c->mapend
i.e. rounded out to whole pages, two consecutive PT_LOAD segments
share
a page.
-> "ELF load command address/offset not page-aligned"
My report quoted only (1) and therefore listed only the packages failing it.
One more package in the very same closure fails (2) on its own:
librtmp1 2.4+20151223.gitfa8646d.1-2+b5 (source: rtmpdump), armhf
LOAD 0 p_offset=0x000000 p_vaddr=0x00000000 p_filesz=0x12d14
-> page extent 0x00000..0x14000
LOAD 1 p_offset=0x013a18 p_vaddr=0x00013a18
-> page extent 0x10000..0x18000
p_vaddr == p_offset in both segments, so condition (1) is satisfied
and the
file looks fine if only that test is applied; but the two page extents
overlap at 16k and ld.so refuses to map it. Confirmed on a 16k-page
kernel:
reverting librtmp1 to this trixie build makes every libcurl-linked 32-bit
binary fail to start again, with the message above naming librtmp.so.1.
So the corrected summary for the closure I surveyed (DT_NEEDED closure of
libcurl4t64 + libgdk-pixbuf-2.0-0 + libssl3t64 + libc6 in trixie/armhf, 48
libraries) is four failing libraries, not three: libpsl.so.5, libz.so.1,
libgmp.so.10 and librtmp.so.1.
Additional request, in the same form as the others:
nmu rtmpdump_2.4+20151223.gitfa8646d.1-2 . armhf . trixie . -m "Rebuild
for 64k section alignment on 32-bit ARM (#1089822): binaries built
before binutils 2.43.50.20241215-1 cannot be loaded on kernels with
pages larger than 4k"
armel is not affected for rtmpdump.
Outside the surveyed closure I also see liblerc4 4.0.0+ds-5 (source: lerc,
built 2024-11-05) failing condition (2); it reaches libtiff6 users. Since
condition (2) can fail on its own, any wider sweep of stale armhf/armel
binaries should test both conditions rather than congruence alone.
Verification from the archive, without 16k-page hardware:
wget
https://deb.debian.org/debian/pool/main/r/rtmpdump/librtmp1_2.4+20151223.gitfa8646d.1-2+b5_armhf.deb
dpkg-deb -x librtmp1_*.deb x
readelf -lW x/usr/lib/arm-linux-gnueabihf/librtmp.so.1 | grep LOAD
# LOAD 0 ends at 0x12d14 -> rounds up to 0x14000 at 16k pages
# LOAD 1 starts at 0x13a18 -> rounds down to 0x10000: the two overlap
Apologies for the incomplete initial analysis.
--
Nenad
