How to Fix CVE-2023-4911 (Looney Tunables) in glibc

CVE-2023-4911, known as Looney Tunables, is a buffer overflow in the glibc dynamic loader (ld.so) that lets a local user gain root by passing a crafted GLIBC_TUNABLES variable to a setuid program. Fix it by installing your distribution’s patched glibc (for example 2.36-9+deb12u3 or RHSA-2023:5453), then restarting services or rebooting.

What the scanner is actually detecting

Nessus reports Looney Tunables through distribution-specific local checks. Each plugin compares the installed glibc packages with the fixed build in one vendor advisory, so the finding only appears in credentialed (SSH) scans. For all five plugins below, Tenable states that Nessus did not test for the flaw and relied on the package’s self-reported version.

The plugins look at every package built from glibc, not only the main library: libc6, libc-bin, libc6-dev, locales and nscd on Debian, and glibc, glibc-common, glibc-langpack-*, libnsl, nscd and nss_db on the RHEL family. Some advisories bundle more than one CVE. DSA-5514-1 also fixes CVE-2023-4527 and CVE-2023-4806 on bookworm, and RHSA-2023:5453 adds CVE-2023-4813, so the same finding can cover several glibc bugs.

The flaw itself: before a program starts, ld.so parses GLIBC_TUNABLES and, for setuid programs, rewrites it to drop unsafe entries. Qualys found that a malformed value such as tunable1=tunable2=AAA makes parse_tunables() write past the end of its buffer. The bug arrived in glibc 2.34 in April 2021. Vendors backported the change into some older branches: Red Hat says RHEL 8.5 and later are affected even though they ship glibc 2.28, and Debian 11 (glibc 2.31) received a fix in the same DSA.

Real-world risk

This is a local privilege escalation with a CVSS v3 score of 7.8. An attacker needs to run commands on the host first, so it is not reachable over the network on its own. Three facts raise its priority:

• Qualys obtained full root on default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, and Debian 12 and 13, using /usr/bin/su as the target.
• Tenable lists public exploits in Metasploit and Core Impact.
• CISA added CVE-2023-4911 to the Known Exploited Vulnerabilities catalog on November 21, 2023, with a federal due date of December 12, 2023. Our guide to the CISA KEV catalog explains how that listing should affect patch order.

Exposure is highest on multi-user shell hosts, CI runners, and servers whose web or application service accounts could be taken over. Not every Linux host is affected: Red Hat states RHEL 8.4 and older are not affected, Debian’s tracker lists Debian 10 as not affected, AWS lists Amazon Linux 1 and 2 as not affected, and Alpine uses musl instead of glibc.

How to confirm it on the host

Check the installed glibc packages. Distribution fixes are backported, so the upstream version (2.36, 2.35, 2.34, 2.28) does not change after patching. Compare the full package release with the table in the next section.

# Debian, Ubuntu
dpkg-query -W libc6 libc-bin
zgrep CVE-2023-4911 /usr/share/doc/libc6/changelog.Debian.gz

# RHEL, AlmaLinux, Oracle Linux, Fedora, Amazon Linux 2023
rpm -qa 'glibc*' nscd libnsl nss_db
rpm -q --changelog glibc | grep CVE-2023-4911

If the changelog grep returns nothing on an RPM system, rely on the version comparison, since not every rebuild names the CVE in its changelog.

Qualys published a quick test that crashes su on a vulnerable loader. It does not give root, but it does produce a crash (and a crash report on hosts running Apport or ABRT), so run it only on systems you are responsible for:

env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" 
  "Z=$(printf '%08192x' 1)" /usr/bin/su --help

“Segmentation fault” means the loader is vulnerable. On a patched host, su prints its usage text instead.

How to fix it

Install the fixed glibc for your release. Any later package from the same repository also contains the fix.

AlmaLinux 8 publishes the RHEL 8 fix as ALSA-2023:5455, which is what plugin 182688 checks. Other Red Hat update streams have their own errata, listed on the Red Hat CVE-2023-4911 page. What matters is that the installed build is at or above the fixed build for the stream the host is subscribed to.

Debian and Ubuntu

sudo apt update
sudo apt install --only-upgrade libc6 libc-bin libc6-dev libc-dev-bin locales nscd
dpkg-query -W libc6 libc-bin

With --only-upgrade, apt skips any listed package that is not installed. A full sudo apt upgrade applies the fix as well.

RHEL, AlmaLinux, Oracle Linux and Fedora

sudo dnf update 'glibc*'
rpm -qa 'glibc*' nscd libnsl nss_db

If nscd, libnsl or nss_db are installed and still show the old release, add them to the update command so every package the plugin checks matches.

Amazon Linux 2023

AL2023 repositories are versioned, so the advisory names the release that carries the fix:

sudo dnf update --advisory ALAS2023-2023-359 --releasever 2023.2.20231002

Restart services or reboot

Installing the package is not the end of the job. Red Hat states that all services linked to glibc must be restarted, or the system rebooted, for the update to take effect, and Ubuntu’s notice says to reboot after a standard system update. Running processes keep the old library mapped until they restart. To see what still uses it (the tools come from the needrestart and dnf-plugins-core packages):

# Debian, Ubuntu (list only, restarts nothing)
sudo needrestart -r l

# RHEL 8/9 family
sudo dnf needs-restarting -r
sudo dnf needs-restarting -s

Because glibc is loaded by nearly every process, a reboot is usually the cleaner option. If you patch many hosts, plan the reboots in waves so clustered services stay up. Container images ship their own glibc, so patching the host does not fix them: rebuild images from an updated base image.

If you cannot patch yet

Red Hat publishes a SystemTap script on its CVE page that kills any setuid program started with GLIBC_TUNABLES in its environment. Load and check it with:

sudo stap -g -F -m stap_block_suid_tunables stap_block_suid_tunables.stp
lsmod | grep -i stap_block_suid_tunables

Red Hat notes it must be loaded again after every reboot and needs extra module-signing steps on Secure Boot systems. It is a stopgap: the Nessus plugins check package versions, so the finding stays open until glibc is updated.

How to verify the fix and rescan

1. Confirm the package release against the table with dpkg-query -W libc6 libc-bin or rpm -qa 'glibc*'.
2. Rerun the Qualys test above. su should print its usage text instead of crashing.
3. Run sudo needrestart -r l or sudo dnf needs-restarting -r and confirm nothing still uses the old library.
4. Rerun the credentialed Nessus scan. The plugins listed above should no longer report on the host. In Nessus Scan Information (plugin 19506), confirm that credentialed checks show yes; if the SSH login failed, local plugins never run and the finding disappears for the wrong reason.

If you loaded the SystemTap mitigation earlier, remove it after patching with sudo rmmod stap_block_suid_tunables.

What can break and how to roll back

The glibc update itself is a targeted security fix; most trouble comes from the restarts it requires. Schedule them like any maintenance window and take a VM snapshot or backup first on critical systems.

Rolling back glibc is possible but risky, because almost every binary depends on it. On the RHEL family, find and undo the transaction:

sudo dnf history list glibc
sudo dnf history undo <transaction-id>

On Debian or Ubuntu, reinstall a specific earlier version if your mirror still carries it: sudo apt install libc6=<previous-version> libc-bin=<previous-version>. Rolling back reopens CVE-2023-4911, so restoring a snapshot and fixing the actual problem is usually safer.

The SystemTap mitigation has its own side effect: a setuid program launched with GLIBC_TUNABLES set is killed. Unset the variable before running such programs, or unload the module with rmmod.

Common false positive reasons

• Backported fixes and version comparison. Patched packages keep the old upstream version. A tool that reads ldd --version or compares only upstream numbers can still flag a patched host, or flag RHEL 8.4 and Debian 10 hosts that were never affected. When the distribution package matches the table, the host is fixed. See why backported patches cause false positives for how to document this.
• Stale results. The report predates the update, or the rescan ran without working credentials.
• Companion packages left behind. Updating libc6 or glibc while nscd, locales or a langpack stays old keeps the plugin firing. This is a real finding against that package, not a false positive.

Two situations are not false positives either: a host with only the SystemTap mitigation in place, and a patched host where services have not yet been restarted. Record the first as mitigated with a patch date, and finish the restart for the second.

FAQ

Can CVE-2023-4911 be exploited remotely?

No. The attacker needs local code execution first, for example through a compromised application or stolen SSH credentials.

Do I need to reboot after the glibc update?

Red Hat requires restarting all services linked to glibc or rebooting, and Ubuntu recommends a reboot. A reboot is the simplest way to be sure.

Does the SystemTap mitigation close the Nessus finding?

No. The plugins compare package versions, so only the fixed glibc package closes it.

Are Alpine and Amazon Linux 2 affected?

No. Alpine uses musl rather than glibc, and AWS lists Amazon Linux 2 as not affected. Amazon Linux 2023 is affected and fixed by ALAS2023-2023-359.

Tracking this finding across many hosts

A glibc fix is only complete when every host has both the new package and a restart, which is hard to prove across a fleet. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus. Its AI can write host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Linux endpoints, and SITEY re-tests afterward to verify closure.

Sources

• Qualys: Looney Tunables advisory for CVE-2023-4911
• Red Hat: CVE-2023-4911 statement and SystemTap mitigation
• Debian: DSA-5514-1 glibc security update
• Ubuntu: USN-6409-1 GNU C Library vulnerabilities
• Tenable: Nessus plugin 182473, Debian DSA-5514-1 : glibc – security update