This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug network/19791] Assertion failure in res_query.c with un-connectable name server addresses
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 30 Mar 2016 21:15:24 +0000
- Subject: [Bug network/19791] Assertion failure in res_query.c with un-connectable name server addresses
- Auto-submitted: auto-generated
- References: <bug-19791-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19791
--- Comment #20 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, gentoo/2.22 has been updated
via b286c83dcbd06314859bf86319782611c81e283d (commit)
from 066bfd462534b7141aaaac23aadc5c0ec3e4e7f3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b286c83dcbd06314859bf86319782611c81e283d
commit b286c83dcbd06314859bf86319782611c81e283d
Author: Florian Weimer <fweimer@redhat.com>
Date: Fri Mar 25 11:49:51 2016 +0100
resolv: Always set *resplen2 out parameter in send_dg [BZ #19791]
Since commit 44d20bca52ace85850012b0ead37b360e3ecd96e (Implement
second fallback mode for DNS requests), there is a code path which
returns early, before *resplen2 is initialized. This happens if the
name server address is immediately recognized as invalid (because of
lack of protocol support, or if it is a broadcast address such
255.255.255.255, or another invalid address).
If this happens and *resplen2 was non-zero (which is the case if a
previous query resulted in a failure), __libc_res_nquery would reuse
an existing second answer buffer. This answer has been previously
identified as unusable (for example, it could be an NXDOMAIN
response). Due to the presence of a second answer, no name server
switching will occur. The result is a name resolution failure,
although a successful resolution would have been possible if name
servers have been switched and queries had proceeded along the search
path.
The above paragraph still simplifies the situation. Before glibc
2.23, if the second answer needed malloc, the stub resolver would
still attempt to reuse the second answer, but this is not possible
because __libc_res_nsearch has freed it, after the unsuccessful call
to __libc_res_nquerydomain, and set the buffer pointer to NULL. This
eventually leads to an assertion failure in __libc_res_nquery:
/* Make sure both hp and hp2 are defined */
assert((hp != NULL) && (hp2 != NULL));
If assertions are disabled, the consequence is a NULL pointer
dereference on the next line.
Starting with glibc 2.23, as a result of commit
e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca (CVE-2015-7547: getaddrinfo()
stack-based buffer overflow (Bug 18665)), the second answer is always
allocated with malloc. This means that the assertion failure happens
with small responses as well because there is no buffer to reuse, as
soon as there is a name resolution failure which triggers a search for
an answer along the search path.
This commit addresses the issue by ensuring that *resplen2 is
initialized before the send_dg function returns.
This commit also addresses a bug where an invalid second reply is
incorrectly returned as a valid to the caller.
(cherry picked from commit b66d837bb5398795c6b0f651bd5a5d66091d8577)
(cherry picked from commit 5a1a5f0dd2744044801c91bf2588444c29cda533)
-----------------------------------------------------------------------
Summary of changes:
resolv/res_send.c | 63 +++++++++++++++++++++++++++++++++-------------------
1 files changed, 40 insertions(+), 23 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.