Bug 1293532 - (CVE-2015-7547) CVE-2015-7547 glibc: getaddrinfo stack-based buffer overflow
CVE-2015-7547 glibc: getaddrinfo stack-based buffer overflow
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 1296028 1296029 1296030 1296031 1296069 1296071 1296073 1296074 1296076 1308943 1309629 1309632 1310202 1310218 1310219
Blocks: 1293533
  Show dependency treegraph
Reported: 2015-12-21 23:36 EST by Fabio Olive Leite
Modified: 2016-03-04 06:23 EST (History)
38 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A stack-based buffer overflow was found in the way the libresolv library performed dual A/AAAA DNS queries. A remote attacker could create a specially crafted DNS response which could cause libresolv to crash or, potentially, execute code with the permissions of the user running the library. Note: this issue is only exposed when libresolv is called from the nss_dns NSS service module.
Story Points: ---
Clone Of:
Last Closed: 2016-02-16 11:58:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 18665 None None None 2016-02-16 09:22 EST

  None (edit)
Description Fabio Olive Leite 2015-12-21 23:36:25 EST
A stack-based buffer overflow was found in libresolv when invoked from nss_dns, allowing specially crafted DNS responses to seize control of EIP in the DNS client.

The buffer overflow occurs in the functions send_dg (send datagram) and send_vc (send TCP) for the NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC family, or in some cases AF_INET6 family.  The use of AF_UNSPEC (or AF_INET6 in some cases) triggers the low-level resolver code to send out two parallel queries for A and AAAA.  A mismanagement of the buffers used for those queries could result in the response of a query writing beyond the alloca allocated buffer created by __res_nquery.
Comment 8 Huzaifa S. Sidhpurwala 2016-02-15 03:33:37 EST

This issue was discovered by the Google Security Team and Red Hat.
Comment 9 Huzaifa S. Sidhpurwala 2016-02-15 03:35:23 EST
External References:

Comment 10 Tomas Hoger 2016-02-16 09:15:24 EST
Public now via:


The announcement links related upstream bug report investigation of which led to the discovery of this issue:

Comment 11 Tomas Hoger 2016-02-16 09:18:07 EST
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1308943]
Comment 12 errata-xmlrpc 2016-02-16 10:20:44 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:0175 https://rhn.redhat.com/errata/RHSA-2016-0175.html
Comment 13 errata-xmlrpc 2016-02-16 10:40:18 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.6 EUS - Server and Compute Node Only
  Red Hat Enterprise Linux 6.2 AUS
  Red Hat Enterprise Linux 6.5 AUS - Server Only
  Red Hat Enterprise Linux 6.4 AUS - Server Only
  Red Hat Enterprise Linux 7.1 EUS - Server and Compute Node Only

Via RHSA-2016:0225 https://rhn.redhat.com/errata/RHSA-2016-0225.html
Comment 14 errata-xmlrpc 2016-02-16 10:41:34 EST
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:0176 https://rhn.redhat.com/errata/RHSA-2016-0176.html
Comment 15 Martin Prpič 2016-02-16 11:36:13 EST
Google's write-up of the issue:

Comment 16 Frank Ch. Eigler 2016-02-16 12:50:39 EST
At some sites, a systemtap-based band-aid for this bug may be suitable as a temporary workaround.  The following script interposes at an interior point in the stub resolver, redirecting T_UNSPEC to T_A queries.  This corresponds to the "do not use AF_UNSPEC" mitigating factor from Carlos' email posting, which Florian and Carlos confirmed should also work for TCP.

It requires systemtap of course, and debuginfo for the version(s) of glibc's libresolv.so.  So on a Fedora machine, run "# debuginfo-install glibc", and repeat for the secondary architecture glibc if installed.  (e.g., glibc-debuginfo*.i686 and glibc-debuginfo*.x86_64).

Then, adjusting /lib*/ to the path or wildcard-path where libresolv may be found:

# stap -g -e '
global T_UNSPEC = 62321
global T_A = 1
probe process("/lib*/libresolv.so.*").function("__libc_res_nquery")
  if ($type == T_UNSPEC ) { $type = T_A }

will instantly, system-wide, quietly perform this single mitigation, as long as the systemtap script remains running.  For example, but bug18665 test program runs to completion instead of suffering the SEGV.  (Add stap -v or -t and/or printf() statements to trace the mitigation's operation.)

Please test it carefully before deploying it seriously, and remember, it's meant only as a temporary band-aid, until a glibc update is fully deployed.
Comment 18 Huzaifa S. Sidhpurwala 2016-02-16 21:41:24 EST

After updating the glibc package on affected systems, it is strongly recommended to reboot the system or restart all the affected services. For more information please refer to: https://access.redhat.com/articles/2161461
Comment 19 Fedora Update System 2016-02-17 07:49:53 EST
glibc-2.21-11.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 20 Fedora Update System 2016-02-17 09:20:31 EST
glibc-2.22-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 22 Robert Scheck 2016-02-18 08:34:21 EST
https://access.redhat.com/articles/2161461 only mentions RHEL 6 and 7, but
what about RHEL 6 or 7 based products such as RHEV (especially RHEV-H)? From
my point of view they should be affected as well, but it's not mentioned at
any place so far. The last RHEV-H Image (for RHEV-M 3.5) is from 2016-01-13.
Comment 23 Frank Ch. Eigler 2016-02-18 08:52:15 EST
Robert, speaking purely generally, it can occur that products such as RHEV-H are assumed to operate in a different environment from a general purpose OS - for example where one where it never contacts untrusted data sources.  So the severity of the same bug may be less, and its fix deferred.
Comment 24 Robert Scheck 2016-02-18 09:17:31 EST
Given GHOST (CVE-2015-0235) was addressed for RHEV-H it would be quite
strange that this CVE is not relevant - while the issue is similar. I
also filed case 01585853 on the Red Hat customer portal now to ensure
that the fix makes it to RHEV-H, because they could consume on untrusted
data sources such as DNS.
Comment 25 Petr Matousek 2016-02-19 10:42:16 EST
(In reply to Robert Scheck from comment #24)

Hi Robert,

we're working on the RHEV-H updates and will release them early next week.

Thank you,
Petr Matousek / Red Hat Product Security
Comment 28 errata-xmlrpc 2016-02-19 17:19:36 EST
This issue has been addressed in the following products:

  RHEV-H and Agents for RHEL-6
  RHEV-H and Agents for RHEL-7

Via RHSA-2016:0277 https://rhn.redhat.com/errata/RHSA-2016-0277.html

Note You need to log in before you can comment on or make changes to this bug.