Fix reply buffer mismanagement in resolver (#730856)
This commit is contained in:
parent
47621c91be
commit
817ee79b35
@ -1,16 +1,52 @@
|
||||
2011-09-01 Andreas Schwab <schwab@redhat.com>
|
||||
|
||||
* resolv/res_query.c (__libc_res_nquery): Update assertion.
|
||||
|
||||
diff -ru a/resolv/res_query.c b/resolv/res_query.c
|
||||
--- a/resolv/res_query.c 2011-12-12 14:10:52.000000000 -0700
|
||||
+++ b/resolv/res_query.c 2011-12-12 14:23:04.832739111 -0700
|
||||
@@ -248,7 +248,7 @@
|
||||
&& *resplen2 > (int) sizeof (HEADER))
|
||||
diff -rup a/resolv/res_query.c b/resolv/res_query.c
|
||||
--- a/resolv/res_query.c 2012-02-16 22:51:17.451796009 -0700
|
||||
+++ b/resolv/res_query.c 2012-02-16 22:54:42.522623598 -0700
|
||||
@@ -122,6 +122,7 @@ __libc_res_nquery(res_state statp,
|
||||
int *resplen2)
|
||||
{
|
||||
HEADER *hp = (HEADER *) answer;
|
||||
+ HEADER *hp2;
|
||||
int n, use_malloc = 0;
|
||||
u_int oflags = statp->_flags;
|
||||
|
||||
@@ -239,26 +240,25 @@ __libc_res_nquery(res_state statp,
|
||||
/* __libc_res_nsend might have reallocated the buffer. */
|
||||
hp = (HEADER *) *answerp;
|
||||
|
||||
- /* We simplify the following tests by assigning HP to HP2. It
|
||||
- is easy to verify that this is the same as ignoring all
|
||||
- tests of HP2. */
|
||||
- HEADER *hp2 = answerp2 ? (HEADER *) *answerp2 : hp;
|
||||
-
|
||||
- if (n < (int) sizeof (HEADER) && answerp2 != NULL
|
||||
- && *resplen2 > (int) sizeof (HEADER))
|
||||
+ /* We simplify the following tests by assigning HP to HP2 or
|
||||
+ vice versa. It is easy to verify that this is the same as
|
||||
+ ignoring all tests of HP or HP2. */
|
||||
+ if (answerp2 == NULL || *resplen2 < (int) sizeof (HEADER))
|
||||
{
|
||||
/* Special case of partial answer. */
|
||||
- assert (hp != hp2);
|
||||
+ assert (n == 0 || hp != hp2);
|
||||
hp = hp2;
|
||||
- /* Special case of partial answer. */
|
||||
- assert (n == 0 || hp != hp2);
|
||||
- hp = hp2;
|
||||
+ hp2 = hp;
|
||||
}
|
||||
else if (answerp2 != NULL && *resplen2 < (int) sizeof (HEADER)
|
||||
- else if (answerp2 != NULL && *resplen2 < (int) sizeof (HEADER)
|
||||
- && n > (int) sizeof (HEADER))
|
||||
+ else
|
||||
{
|
||||
- /* Special case of partial answer. */
|
||||
- assert (hp != hp2);
|
||||
- hp2 = hp;
|
||||
+ hp2 = (HEADER *) *answerp2;
|
||||
+ if (n < (int) sizeof (HEADER))
|
||||
+ {
|
||||
+ hp = hp2;
|
||||
+ }
|
||||
}
|
||||
|
||||
+ /* Make sure both hp and hp2 are defined */
|
||||
+ assert((hp != NULL) && (hp2 != NULL));
|
||||
+
|
||||
if ((hp->rcode != NOERROR || ntohs(hp->ancount) == 0)
|
||||
&& (hp2->rcode != NOERROR || ntohs(hp2->ancount) == 0)) {
|
||||
#ifdef DEBUG
|
||||
|
@ -28,7 +28,7 @@
|
||||
Summary: The GNU libc libraries
|
||||
Name: glibc
|
||||
Version: %{glibcversion}
|
||||
Release: 18%{?dist}
|
||||
Release: 19%{?dist}
|
||||
# GPLv2+ is used in a bunch of programs, LGPLv2+ is used for libraries.
|
||||
# Things that are linked directly into dynamically linked programs
|
||||
# and shared libraries (e.g. crt files, lib*_nonshared.a) have an additional
|
||||
@ -90,6 +90,8 @@ Patch27: %{name}-rh564528.patch
|
||||
Patch28: %{name}-rh790292.patch
|
||||
Patch29: %{name}-rh790298.patch
|
||||
Patch30: %{name}-rh791161.patch
|
||||
# Aurelien submitted upstream, Uli has largely ignored
|
||||
Patch31 : %{name}-rh730856.patch
|
||||
|
||||
|
||||
Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
|
||||
@ -339,6 +341,7 @@ rm -rf %{glibcportsdir}
|
||||
%patch28 -p1
|
||||
%patch29 -p1
|
||||
%patch30 -p1
|
||||
%patch31 -p1
|
||||
|
||||
# A lot of programs still misuse memcpy when they have to use
|
||||
# memmove. The memcpy implementation below is not tolerant at
|
||||
@ -1191,6 +1194,9 @@ rm -f *.filelist*
|
||||
%endif
|
||||
|
||||
%changelog
|
||||
* Fri Feb 17 2012 Jeff Law <law@redhat.com> - 2.15-19
|
||||
- Fix reply buffer mismanagement in resolver (#730856)
|
||||
|
||||
* Thu Feb 16 2012 Jeff Law <law@redhat.com> - 2.15-18
|
||||
- Revert 552960/769421 changes again, still causing problems.
|
||||
- Add doi_IN (#791161)
|
||||
|
Loading…
Reference in New Issue
Block a user