Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: binnmu
Dear Stable Release Managers,
The armhf and armel binaries of three packages in trixie were built before
binutils restored 64k section alignment for 32-bit ARM (#1089822, fixed in
binutils 2.43.50.20241215-1 via debian/patches/armhf-64k-alignment.diff).
As a result ld.so refuses to load them on kernels whose page size is larger
than 4k -- for example Debian's own arm64 kernel with 16k pages and compat
support, or the default Raspberry Pi 5 kernel.
glibc's check, elf/dl-load.c:
if (__glibc_unlikely (((ph->p_vaddr - ph->p_offset)
& (GLRO(dl_pagesize) - 1)) != 0))
errstring = N_("ELF load command address/offset not page-aligned");
The affected binaries in trixie/armhf, second PT_LOAD of each:
libpsl5t64 0.21.2-1.1+b1 libpsl.so.5.3.4
p_offset=0x00ee30 p_vaddr=0x0000fe30 delta=0x1000
zlib1g 1:1.3.dfsg+really1.3.1-1+b1 libz.so.1.3.1
p_offset=0x010e1c p_vaddr=0x00011e1c delta=0x1000
libgmp10 2:6.3.0+dfsg-3 libgmp.so.10.5.0
p_offset=0x051d60 p_vaddr=0x00052d60 delta=0x1000
delta mod 16384 = 4096 in each case, so the load fails. On armel the same
applies to libpsl5t64 and zlib1g; libgmp10/armel happens to come out
congruent and is not affected.
No source change is involved -- a plain rebuild is sufficient. The same
source version built either side of the binutils fix shows this directly:
libxcb1 1.17.0-2+b1 (trixie/armhf) second PT_LOAD delta 0x1000,
p_align 0x1000
libxcb1 1.17.0-2+b2 (sid/armhf) second PT_LOAD delta 0x10000,
p_align 0x10000
Unstable already carries correctly aligned builds of all three packages
(libpsl 0.23.3-1, zlib 1:1.3.dfsg+really1.3.2-3, gmp 2:6.3.0+dfsg-5+b2),
so only stable is affected.
Impact: libpsl and zlib are in the DT_NEEDED closure of libcurl4t64, so any
32-bit armhf program linked against libcurl fails to start on a 16k-page
kernel with
error while loading shared libraries: libpsl.so.5: ELF load command
address/offset not page-aligned
I checked the complete DT_NEEDED closure of libcurl4t64 +
libgdk-pixbuf-2.0-0
+ libssl3t64 + libc6 as shipped in trixie/armhf: 48 libraries, of which
exactly these three fail. Every package in that closure built on or after
2024-12-15 is correctly aligned and every one built before it is not, which
matches the binutils upload date. Parts of the archive outside this closure
were not surveyed and may contain further stale armhf/armel binaries.
Requested for the next trixie point release:
nmu libpsl_0.21.2-1.1 . armhf armel . trixie . -m "Rebuild for 64k
section alignment on 32-bit ARM (#1089822): binaries built before
binutils 2.43.50.20241215-1 fail to load on kernels with pages larger
than 4k"
nmu zlib_1:1.3.dfsg+really1.3.1-1 . armhf armel . trixie . -m "Rebuild
for 64k section alignment on 32-bit ARM (#1089822): binaries built
before binutils 2.43.50.20241215-1 fail to load on kernels with pages
larger than 4k"
nmu gmp_2:6.3.0+dfsg-3 . armhf . trixie . -m "Rebuild for 64k section
alignment on 32-bit ARM (#1089822): binaries built before binutils
2.43.50.20241215-1 fail to load on kernels with pages larger than 4k"
The defect can be confirmed without 16k-page hardware, from the archive
alone:
wget
https://deb.debian.org/debian/pool/main/libp/libpsl/libpsl5t64_0.21.2-1.1+b1_armhf.deb
dpkg-deb -x libpsl5t64_0.21.2-1.1+b1_armhf.deb x
readelf -lW x/usr/lib/arm-linux-gnueabihf/libpsl.so.5.3.4 | grep LOAD
# second LOAD: p_vaddr - p_offset = 0x1000, not a multiple of 16384
Thanks in advance for considering this.
--
Nenad
