GPU VulnDB

Database/Kernel, userspace & hypervisor

glibc getaddrinfo: use-after-free crashes the calling process in a narrow NSS configuration

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

Impact

getaddrinfo can touch freed memory and crash the calling application, but only in a tightly constrained setup: an NSS module that implements _nss_*_gethostbyname2_r and _nss_*_getcanonname_r without _nss_*_gethostbyname3_r, a resolved name returning a large number of both IPv6 and IPv4 addresses, and a call using AF_INET6 with AI_CANONNAME, AI_ALL and AI_V4MAPPED. Red Hat calls the situation extremely rare and the recorded impact is availability of the process only, with high attack complexity. Most datacenter hosts run the stock files/dns NSS stack and are not affected; hosts using a third-party NSS module (some directory or cluster-naming integrations) are the ones to check. Worth patching because glibc sits under every daemon on a GPU node, not because this is a likely exploit path.

Who can reach it

An attacker who controls the DNS or directory answer for a name the host resolves, against a process making the specific AF_INET6 / AI_CANONNAME / AI_ALL / AI_V4MAPPED call on a host with a qualifying NSS module. No authentication, but the preconditions do most of the work.

What to do

Update glibc through the vendor errata (RHSA-2023:5453, 5455, 7409) or your distribution's equivalent. Every process holds its own copy of the old library, so the update only takes effect after the services that use it restart - on a GPU node with long-lived driver, container and serving daemons, a reboot during the next maintenance window is the straightforward way to be sure. Check whether any non-default NSS module is configured before treating this as urgent.

References

Related entries

All Kernel, userspace & hypervisor entries

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.