Dear Maintainer,

glibc as part of Debian Bookworm is affected by the following upstream
bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25847

To avoid confusion I'm not repeating the details here. The result is a
broken synchronization primitive. condition variables might miss a
wakeup event.

The issue is fixed in glibc 2.41 and newer.

There is a patch series targeting the 2.36 branch available at
https://inbox.sourceware.org/libc-stable/20250722150321.2251739-1-sunilkumar.dora@windriver.com/

Upstream did not apply the series yet. There have been concerns about
breaking existing software - which should not affect Debian. More
details in the referenced upstream bug.

The patches can be applied as is to the Debian bookworm glibc based on
2.36. I'm running that for some time now, the reproducer is no longer
working inside a Debian 12 podman container.

Is there a chance that we get this bug fixed in Debian bookworm?

Hi Florian,

Yes, this is bug #986724.

Looking at the upstream details, it indeed seems that Debian is not
affected by the RPM issue. That said, as we only restart processes for
major glibc upgrades, I suspect than some other packages (using db5.3 or
also using process-shared condition variables in files on disk) might be
affected by the fix, as well as third party software.

At this stage I am not fully convinced:

- It is not clear to me which software is currently affected by this
  bug, and thus it's difficult to judge how important is it to fix this
  bug, especially given this is not a regression from bullseye (the bug
  is present in that version). Do you have some real examples of
  affected software that can show it's important to fix this bug in
  bookworm?

- As said above, there is a risk of breakage, which many users would not
  expect now that bookworm is 2+ years old. The bookworm to trixie
  upgrade, is different because users expect some breakages for such a
  major upgrade and as it is a major glibc upgrade, services were
  restarted and systems are often rebooted afterwards.

- We have fewer autopkgtest in bookworm than for trixie, which reduces
  the chances of catching regressions before they reach a point release.

In the end we'll need to convince the release team that the bug is
important to fix and there is minimal risk to include it in a point
release.

In any case I would prefer to avoid including this in the next bookworm
point release (12.14, scheduled for 16 May) as there are already 5 CVE
(+1 pending) to be fixed win this update. I would prefer to avoid the
risk of delaying the glibc update to the next point release in case an
issue is found.

Best regards
Aurelien

Hi Aurelien,

That's hard to tell. I'm quite sure that there are Debian package
affected by this problem but the "lockup" isn't happening that often, so
that those problems likely stay unreported.

In our case the 3rd party application is based on the libace, which is
also part of Debian. libace is implementing a thread pool based on
condition variables. AFAIK the infrastructure around ACE_Task. Threads
don't wake up when there is some work to do. 

I'm quite sure the same pattern is implemented within other Debian
packages as well.

Valid point. See below. Maybe we can do something on the testing side?

Can we do something on the testing side to get better confidence?

We're internally stressing the patched glibc package for a couple of
days now. The update path was also part of that testing, but for sure we
can't cover all possible scenarios.

Normally a package would go through the unstable -> testing -> stable
chain, which is not possible here because the bug is already fixed in
newer releases. Could we use something like "proposed updates" to get
additional feedback, so that we could consider this update for the next
+ 1 point release?

Any other ideas?

The upstream bug report mentions a couple of other 3rd party software
now implementing a workaround for that issue. Broadcasting the condition
variable, waking up all threads where n-1 threads go to sleep again
immediately. This is a big performance penalty in case a lot of threads
are involved.

Best regards,
Florian

Hi Florian,

Ok, thanks for the details. I have noticed that libace does not have any
packages depending on it. It would be interested to known if any other
package in the archive suffer from the same issue.

The problem is to identify software that might be broken by the fix,
then testing is the easy part.

From what I understand from the upstream bug log, at least packages
using db5.3 have a risk to get broken when upgrading to the fixed glibc,
unless they are restarted (that's the reason why it's an issue on RPM
based distributions). The db-5.3.28-condition_variable.patch should fix
that, but it is not applied in the debian db5.3 package (not even in
unstable). It applies cleanly though.

Yes, packages go through -proposed-updates before going to (old-)stable
for a point release. But far less people are using that than testing, so
I am not sure about the coverage we'll get. But if we decide to apply
the patch series, we need to do that just after the point release to
increase the testing time and the chance to catch issues.

Yes, the bug has attracted many different people, showing that the bug
is not a corner case but a real issue. I just don't want to fix a bug to
open a different one, so at this stage I am not sure what to do.

Regards
Aurelien

Hi Aurelien,

The point release (12.14) has been released a couple of days ago. Sadly
we did not get any further comments / input / feedback regarding this
issue. How do we proceed now?

Our tests are still ongoing, all looking good so far. No additional
issues came up. I would love to increase the test coverage and to move
forward, but options seem limited.

Best regards,
Florian

Hi,

On my side, I still not sure how to get this patchset properly tested, especially
for the db5.3 case. The only option I see is to get the package into
stable-proposed-updates, ask users to test it and cross our fingers that
any issues are detected before the point release. But that's not feel
very comfortable though.

Great. Have your tests covered the db5.3 case as well?

Regards
Aurelien

Hi,

Nope, for the following two reasons:

- I'm not sure what exactly needs to be patched into db5.3 to "fix" it.
  Seems there are two fixes needed: 
  
  a) The initializer of glibc, so you have to rebuild against a 
     "fixed glibc". Covered by the glibc patch series. Done.
  
  b) Something named re-initialization patch and seems to be available
     via [1], taken from the upstream glibc bug report.

- Even if I would be able to "fix" or patch the db5.3 package I have no
  idea how to make sure that the problem is gone. For the glibc issue
  I have two reproducers (available via upstream bug report) and
  our own application. For db5.3 I'm missing something similar.

[1] https://gitlab.com/redhat/centos-stream/rpms/libdb/-/blob/c9s/db-5.3.28-condition_variable.patch?ref_type=heads