On 2025-02-26 06:34:58 +0100, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: gl...@packages.debian.org > Control: affects -1 + src:glibc > User: release.debian....@packages.debian.org > Usertags: transition > > Dear release team, > > I would like to get a transition slot for glibc 2.41. It has been > available in experimental only for almost a month, and it looks in good > state. I would also like to have this version in Trixie, in order to > avoid shipping a one-year-old version in Trixie and to make the > maintenance (i.e. backporting fixes) during the Trixie lifecycle > simpler. It has been built successfully on all release architectures and > most ports architectures. > > One important change is that starting with this version, the dlopen and > dlmopen functions no longer make the stack executable if a shared > library requires it and instead just fail. This change aims to improve > security, as the previous behaviour was used as a vector for RCE > (CVE-2023-38408). I have therefore scanned the archive (on amd64) to > find ELF files with executable stack, and found this affects 45 > packages. After excluding files not linked against glibc, binaries, > libraries opened from a binary with an executable stack, and libraries > that are clearly not used through dlopen, I ended up with the following > list of possibly or surely affected packages: > - mrgingham_1.24-2 > - pdp_1:0.14.1+darcs20180201-6 > - postgresql-pllua_1:2.0.12-3 > - rccl_5.4.3-3 > - rocm-hipamd_5.7.1-5 > - swupdate_2024.12.1+dfsg-1 > - uwsgi-plugin-pypy_0.0.2 > In most of the cases the executable stack is due to a missing > .note.GNU-stack note (which defines if the stack needs to be executable > or not). Binutils defaulted to an executable stack in an absence of this > note, but this has been changed in version 2.44-2 (which is now in > testing). This means all the above except mrgingham can be fixed by a > binNMU against binutils >= 2.44-2. For mrgingham, a patch is available > in the BTS (#1098892).
binNMUs for those have been scheduled. Cheers > The experimental pseudo-excuses look good overall, besides the usual > issues with britney and some packages that can't be really tested with > experimental. The others are: > - glibc/arm64: this is fixed in git > - bart-cuda (not in testing): reported as #1096018 > - mrgingham: reported as #1098892 > - postgresql-pllua: reported as #1096038 (can be fixed with a binNMU) > > As glibc is using symbol versioning, there is no soname change. That > said a few packages are using libc internal symbols and have to be > rebuilt for this transition. Here is the corresponding ben file: > > title = "glibc"; > is_affected = .depends ~ /libc[0-9.]* \(<</; > is_good = .depends ~ /libc[0-9.]* \(<< 2.42\)/; > is_bad = .depends ~ /libc[0-9.]* \(<< 2.41\)/; > > This version does not provide existing symbols with a GLIBC_2.41 > version, however it adds the sched_setattr and sched_getattr symbols to > libc and the acospi*, asinpi*, atan2pi*, atanpi*, cospi*, sinpi*, tanpi* > ISO C23 trigonometric functions to libm. They are unlikely to be used at > this point, so this should not block package migration to testing during > the transition. > > Thanks for considering. > > Regards, > Aurelien > -- Sebastian Ramacher
