glibc: getaddrinfo use-after-free crashes applications when nsswitch uses SUCCESS=continue/merge

CVSS 5.9CVE-2023-4813Kernel, userspace & hypervisorcurated

Impact

gaih_inet can use already-freed memory during a getaddrinfo call, crashing the calling application. The record describes this as reachable only when /etc/nsswitch.conf configures the hosts database with SUCCESS=continue or SUCCESS=merge, which is not the default on RHEL-family systems - so most fleets are not exposed, and that configuration is worth checking before scheduling anything. Where it is set, the affected path is name resolution, which every daemon on a GPU node touches: schedulers, NCCL rendezvous, storage clients, telemetry agents. The stated impact is availability (crash); the record does not claim code execution.

Who can reach it

Network-adjacent and unauthenticated in principle - the trigger is DNS response data processed during getaddrinfo - but only on hosts whose nsswitch hosts line uses SUCCESS=continue or SUCCESS=merge. On a default configuration the path is not reachable.

What to do

Apply the glibc updates for your RHEL stream (RHSA-2023:5453, RHSA-2023:5455, RHSA-2023:7409). A glibc update means every process using the old library keeps it until restarted, so in practice this is a node reboot to be sure, which on a GPU node means drain first. Cheap mitigation if you cannot reboot soon: confirm /etc/nsswitch.conf does not use SUCCESS=continue or SUCCESS=merge on the hosts line, in which case the flaw is not reachable.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-4813 https://access.redhat.com/security/cve/CVE-2023-4813 https://access.redhat.com/errata/RHSA-2023:5453 https://bugzilla.redhat.com/show_bug.cgi?id=2237798

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.