glibc: getaddrinfo in no-aaaa mode leaks stack contents from a large TCP DNS response

CVSS 6.5CVE-2023-4527Kernel, userspace & hypervisorcurated

Impact

When /etc/resolv.conf sets no-aaaa mode and an application calls getaddrinfo with AF_UNSPEC, a DNS response arriving over TCP larger than 2048 bytes can cause stack contents to be returned in the address data, or crash the process. Every daemon on a GPU node resolves names through glibc - the container runtime pulling images, the scheduler agent, telemetry shippers - so an attacker who controls or can spoof a DNS answer gets a slow read of process stack memory from any of them, with pointers and secrets as plausible content, or just drops the resolver-dependent service. The precondition is the no-aaaa option, which is uncommon but does get set in IPv6-free datacenter builds; hosts without it are not affected.

Who can reach it

Remote and unauthenticated but indirect (CVSS AV:N/AC:H/PR:N): the attacker must be able to return an oversized TCP DNS response to the node - an operator-controlled or compromised resolver, an upstream authoritative server for a name the host looks up, or an on-path position - and the host must have no-aaaa configured.

What to do

Update glibc from the Red Hat errata (RHSA-2023:5453, RHSA-2023:5455). glibc is linked into every running process, so coverage requires restarting all services that resolve names, and in practice operators reboot the node to be sure - a drain-and-reboot pass. Immediate mitigation with no downtime: remove the no-aaaa option from /etc/resolv.conf, which closes the affected path entirely.

References

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

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.