Check out phoronix.com glibc has had a big security flaw since 2.34, big enough for critical Debian Servers to go "shields up" until patched.
X also has a few vulnerabilities in it that have gone undiscovered since I was grad school ( I saw Jerry Garcia live my freshman year and he had years of touring left in him).

Here's some actual information:
* Qualys announced a Local Privilege Escalation in the glibc's ld.so that grants full root privileges.
* Most distros use glibc and will be affected - Debian, Fedora and Ubuntu, were all cited, but only a few (like Alpine) do not use glibc and so will avoid the issue.
* Security code is CVE-2023-4911

It is not specific to glibc 2.34 - there are patches for 2.31 in Debian 11 Bullseye and 2.36 in Debian 12 Bookworm both released today.
(At time of writing Debian's security tracker shows Testing and Unstable remain vulnerable; a reminder that these are not secure releases but development tools.)

If in doubt, simply make sure your OS has security updates enabled and update.

1 members found this post helpful.

I'm not actually qualified to give actual information so heads up is all I can give.

1 members found this post helpful.

I'm guessing Linux caps would be a good way not to have to deal with this? I try to use caps in place of setuid whenever I can.

This is already patched in my distro. I feel bad for the IT pros that have to patch all those machines and restart all those servers!

The good news are that the X vulnerabilities apparently haven't hit anyone during the past 38 years...

Debian unstable has :
(Debian GLIBC 2.37-12) 2.37
already updated and fixed.

How can I reconcile these apparently contradictory statements, in particular with reference to pre-2.34 glibc such as 2.31?
Do you conclude that because Debian patched 2.31, 2.31 has the exploit?
My concern arises because I run the stable edition of Slackware-64, version 15.0.
It has a pre-2.34 (2.33) glibc.

I conclude that Debian's 2.31-13+deb11u6 has the exploit because Debian released an advisory stating it is vulnerable to the exploit, along with version 2.31-13+deb11u7 to resolve that vulnerability.

If the flaw was introduced in April 2021, then presumably it was carried over with one of the eight updates that Debian's 2.31 received between April 2021 and now.

Whether Slackware's version has the exploit is a question for Slackware's Security Team.

Given that glibc is a core package, the lack of any Slackware security advisory probably means that it does not, but being neither a Slackware user nor on their Security Team, I cannot confirm that.

I think you're saying the flaw introduced into glibc 2.34 was probably back-ported by Debian into their copy of 2.31. That clears it up for me, thank you.

Does Debian provide a documented list of all updates that have been made available to Debian 12? As an example you want to check if all updates have been applied to your system is there a document showing all updates made available ?

You can see the history of everything installed, upgraded and removed in the logs in /var/log/apt. You can see the changelog for each package with apt-get changelog <package>. You can also use apt-cache policy <package> to see the currently installed version and the update candidate.

based on the documentation here is the way to check it:
if the host is vulnerable you will get a segfault, otherwise you will get the normal help page of su.