Bug#1145777: nmu: libpsl_0.21.2-1.1, zlib_1:1.3.dfsg+really1.3.1-1, gmp_2:6.3.0+dfsg-3 (armhf/armel, trixie)

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