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

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