Bug#1098925: transition: glibc 2.41
On 2025-02-28 19:04:25 +0100, Aurelien Jarno wrote:
> On 2025-02-26 09:30, Emilio Pozuelo Monfort wrote:
> > Control: tags -1 confirmed
> >
> > Hi Aurelien,
> >
> > On 26/02/2025 06:34, Aurelien Jarno wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > X-Debbugs-Cc: glibc@packages.debian.org
> > > Control: affects -1 + src:glibc
> > > User: release.debian.org@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).
> > >
> > > 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.
> >
> > Go ahead.
>
> Thanks, I have just uploaded it.
Thanks, binNMUs with --extra-depends "libc-bin (>= 2.41)" scheduled.
Cheers
--
Sebastian Ramacher
Reply to: