CVE-2023-4911 — Glibc: buffer overflow in ld.so leading to privilege escalation

Exploitation evidence

Known exploited · CISA KEV listed

Added 2023-11-21. Ransomware campaign use: Unknown.

CISA required action: Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable.

CISA due date: 2023-12-12. This is the catalog’s deadline, not an assessment of your organization’s exposure.

KEV checked 13 Nov 2026, 00:20 Jerusalem · Original catalog ↗

Reported products and versions

/

Default status: unaffected

affected: 2.34 to < 2.39 (custom)

Red Hat / Red Hat Enterprise Linux 8

Default status: affected

unaffected: 0:2.28-225.el8_8.6 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 8

Default status: affected

unaffected: 0:2.28-225.el8_8.6 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 8.6 Extended Update Support

Default status: affected

unaffected: 0:2.28-189.6.el8_6 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 9

Default status: affected

unaffected: 0:2.34-60.el9_2.7 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 9

Default status: affected

unaffected: 0:2.34-60.el9_2.7 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 9.0 Extended Update Support

Default status: affected

unaffected: 0:2.34-28.el9_0.4 to < * (rpm)

Red Hat / Red Hat Virtualization 4 for Red Hat Enterprise Linux 8

Default status: affected

unaffected: 0:2.28-189.6.el8_6 to < * (rpm)

Red Hat / Red Hat Virtualization 4 for Red Hat Enterprise Linux 8

Default status: affected

unaffected: 0:4.5.3-10.el8ev to < * (rpm)

Red Hat / Red Hat Virtualization 4 for Red Hat Enterprise Linux 8

Default status: affected

unaffected: 0:4.5.3-202312060823_8.6 to < * (rpm)

Red Hat / Red Hat Enterprise Linux 6

Default status: unaffected

Red Hat / Red Hat Enterprise Linux 7

Default status: unaffected

Red Hat / Red Hat Enterprise Linux 7

Default status: unaffected

Fixes and workarounds

No explicit solution text in the downloaded CVE record. Consult the vendor advisory; unaffected version ranges are shown above as reported, not inferred as a patch recommendation.

Reported workarounds: For customers who cannot update immediately and do not have Secure Boot feature enabled, the issue can be mitigated using the provided SystemTap script with the following steps. When enabled, any setuid program invoked with GLIBC_TUNABLES in the environment will be terminated immediately. To invoke the setuid program, users will then have to unset or clear the GLIBC_TUNABLES envvar, e.g. `GLIBC_TUNABLES= sudo` . Note that these mitigation steps will need to be repeated if the system is rebooted. 1) Install required systemtap packages and dependencies as per - https://access.redhat.com/solutions/5441 2) Create the following systemtap script, and name it stap_block_suid_tunables.stp: ~~~ function has_tunable_string:long() { name = "GLIBC_TUNABLES" mm = @task(task_current())->mm; if (mm) { env_start = @mm(mm)->env_start; env_end = @mm(mm)->env_end; if (env_start != 0 && env_end != 0) while (env_end > env_start) { cur = user_string(env_start, ""); env_name = tokenize(cur, "="); if (env_name == name && tokenize("", "") != "") return 1; env_start += strlen (cur) + 1 } } return 0; } probe process("/lib*/ld*.so*").function("__tunables_init") { atsecure = 0; /* Skip processing if we can't read __libc_enable_secure, e.g. core dump handler (systemd-cgroups-agent and systemd-coredump). */ try { atsecure = @var("__libc_enable_secure"); } catch { printk (4, sprintf ("CVE-2023-4911: Skipped check: %s (%d)", execname(), pid())); } if (atsecure && has_tunable_string ()) raise (9); } ~~~ 3) Load the systemtap module into the running kernel: ~~~ stap -g -F -m stap_block_suid_tunables stap_block_suid_tunables.stp ~~~ 4) Ensure the module is loaded: ~~~ lsmod | grep -i stap_block_suid_tunables stap_block_suid_tunables 249856 0 ~~~ 5) Once the glibc package is updated to the version containing the fix, the systemtap generated kernel module can be removed by running: ~~~ rmmod stap_block_suid_tunables ~~~ If Secure Boot is enabled on a system, the SystemTap module must be signed. An external compiling server can be used to sign the generated kernel module with a key enrolled into the kernel's keyring or starting with SystemTap 4.7 you can sign a module without a compile server. See further information here - https://www.redhat.com/sysadmin/secure-boot-systemtap

Sources and related reporting

CVE Program record ↗ · Download tracked evidence as JSON