How the glibc DNS Buffer Overflow (CVE‑2015‑7547) Threatens Linux Servers and What to Do

Researchers have uncovered a high‑severity vulnerability in the GNU C Library (glibc) that resides in the DNS client resolver function getaddrinfo(). The flaw, identified as CVE‑2015‑7547, enables remote code execution on modern Linux servers.

The vulnerability is a heap‑based buffer overflow triggered when getaddrinfo() processes DNS responses larger than 2048 bytes. It has been patched, but any system using glibc 2.9 or later (released May 2008) is potentially affected. Red Hat Enterprise Linux 5 (glibc 2.5) is safe, while RHEL 6 (glibc 2.12), RHEL 7 (glibc 2.17), Debian squeeze (glibc 2.11), wheezy (glibc 2.13) and jessie (glibc 2.19) are vulnerable.

The issue was first reported by Robert Holiday of Ciena in July 2015. Red Hat engineers Carlos O’Donnell and Florian Weiner evaluated its impact and prepared patches. Independently, Google researchers Fermin J. Serna and Kevin Stadmeyer discovered the same bug and released a proof‑of‑concept exploit.

Exploitation works by directing a victim to a malicious DNS server. Because many applications—including ssh, sudo and curl—rely on getaddrinfo(), an attacker can gain control of the host. The attack requires a crafted DNS response of exactly 2048 bytes, followed by a second response that carries up to 63 487 bytes of payload.

Mitigation steps are: immediately apply the glibc security patch; if patching is not possible, limit the size of DNS responses accepted by the local resolver to 1024 bytes. This temporary measure may break DNSSEC/EDNS0 functionality, which often needs UDP responses larger than 512 bytes, potentially causing resolution failures or noticeable latency.

Additional defensive measures include enforcing the use of trusted resolvers, blocking all outbound DNS traffic except to known resolvers, and disabling dual A/AAAA queries. Disabling IPv6 alone does not prevent the exploit because the payload can still be delivered via IPv4.

The patch is publicly available, but remediation can be lengthy for embedded devices and mobile applications that embed glibc deeply, making swift detection and patching essential.