summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSona Sarmadi <sona.sarmadi@enea.com>2016-02-26 11:41:05 (GMT)
committerTudor Florea <tudor.florea@enea.com>2016-02-26 12:25:45 (GMT)
commitb313001a4762cce6eca3d57fcd7f4c0f59d5d4e0 (patch)
tree314160081a8ccc269203746395004a597a98f7cd
parente39962398625aeb780b2f8a08b194f35ded8b4b8 (diff)
downloadpoky-b313001a4762cce6eca3d57fcd7f4c0f59d5d4e0.tar.gz
glibc: CVE-2015-7547
getaddrinfo stack-based buffer overflow References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547 https://sourceware.org/bugzilla/show_bug.cgi?id=18665 https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com> Signed-off-by: Tudor Florea <tudor.florea@enea.com>
-rw-r--r--meta/recipes-core/glibc/glibc/CVE-2015-7547.patch621
-rw-r--r--meta/recipes-core/glibc/glibc_2.20.bb1
2 files changed, 622 insertions, 0 deletions
diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
new file mode 100644
index 0000000..46abd4f
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-7547.patch
@@ -0,0 +1,621 @@
1From: Carlos O'Donell <carlos@systemhalted.org>
2Date: Wed, 17 Feb 2016 02:26:37 +0000 (-0500)
3CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug 18665).
4X-Git-Url: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff_plain;h=16d0a0ce7613552301786bf05d7eba8784b5732c;hp=014eaa22077fd4759083b1a4619ded513a181f92
5
6CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug 18665).
7
8* A stack-based buffer overflow was found in libresolv when invoked from
9 libnss_dns, allowing specially crafted DNS responses to seize control
10 of execution flow in the DNS client. The buffer overflow occurs in
11 the functions send_dg (send datagram) and send_vc (send TCP) for the
12 NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
13 family. The use of AF_UNSPEC triggers the low-level resolver code to
14 send out two parallel queries for A and AAAA. A mismanagement of the
15 buffers used for those queries could result in the response of a query
16 writing beyond the alloca allocated buffer created by
17 _nss_dns_gethostbyname4_r. Buffer management is simplified to remove
18 the overflow. Thanks to the Google Security Team and Red Hat for
19 reporting the security impact of this issue, and Robert Holiday of
20 Ciena for reporting the related bug 18665. (CVE-2015-7547)
21
22See also:
23https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
24https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html
25
26(cherry picked from commit e9db92d3acfe1822d56d11abcea5bfc4c41cf6ca)
27
28Upstream-Status: Backport
29CVE: CVE-2015-7547
30---
31
32diff -ruN a/ChangeLog b/ChangeLog
33--- a/ChangeLog 2016-02-26 07:47:00.616487856 +0100
34+++ b/ChangeLog 2016-02-26 07:56:25.557433548 +0100
35@@ -1,3 +1,18 @@
36+2016-02-15 Carlos O'Donell <carlos@redhat.com>
37+
38+ [BZ #18665]
39+ * resolv/nss_dns/dns-host.c (gaih_getanswer_slice): Always set
40+ *herrno_p.
41+ (gaih_getanswer): Document functional behviour. Return tryagain
42+ if any result is tryagain.
43+ * resolv/res_query.c (__libc_res_nsearch): Set buffer size to zero
44+ when freed.
45+ * resolv/res_send.c: Add copyright text.
46+ (__libc_res_nsend): Document that MAXPACKET is expected.
47+ (send_vc): Document. Remove buffer reuse.
48+ (send_dg): Document. Remove buffer reuse. Set *thisanssizp to set the
49+ size of the buffer. Add Dprint for truncated UDP buffer.
50+
51 2016-01-27 Paul Eggert <eggert@cs.ucla.edu>
52
53 [BZ #18240]
54diff -ruN a/NEWS b/NEWS
55--- a/NEWS 2016-02-26 07:46:59.880543941 +0100
56+++ b/NEWS 2016-02-26 07:57:53.894701123 +0100
57@@ -26,6 +26,20 @@
58 17153, 17187, 17213, 17259, 17261, 17262, 17263, 17319, 17325, 17354,
59 17625, 17630.
60
61+* A stack-based buffer overflow was found in libresolv when invoked from
62+ libnss_dns, allowing specially crafted DNS responses to seize control
63+ of execution flow in the DNS client. The buffer overflow occurs in
64+ the functions send_dg (send datagram) and send_vc (send TCP) for the
65+ NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC
66+ family. The use of AF_UNSPEC triggers the low-level resolver code to
67+ send out two parallel queries for A and AAAA. A mismanagement of the
68+ buffers used for those queries could result in the response of a query
69+ writing beyond the alloca allocated buffer created by
70+ _nss_dns_gethostbyname4_r. Buffer management is simplified to remove
71+ the overflow. Thanks to the Google Security Team and Red Hat for
72+ reporting the security impact of this issue, and Robert Holiday of
73+ Ciena for reporting the related bug 18665. (CVE-2015-7547)
74+
75 * The nss_dns implementation of getnetbyname could run into an infinite loop
76 if the DNS response contained a PTR record of an unexpected format.
77
78diff -ruN a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
79--- a/resolv/nss_dns/dns-host.c 2016-02-26 07:46:55.148904530 +0100
80+++ b/resolv/nss_dns/dns-host.c 2016-02-26 07:48:34.137360778 +0100
81@@ -1031,7 +1031,10 @@
82 int h_namelen = 0;
83
84 if (ancount == 0)
85- return NSS_STATUS_NOTFOUND;
86+ {
87+ *h_errnop = HOST_NOT_FOUND;
88+ return NSS_STATUS_NOTFOUND;
89+ }
90
91 while (ancount-- > 0 && cp < end_of_message && had_error == 0)
92 {
93@@ -1208,7 +1211,14 @@
94 /* Special case here: if the resolver sent a result but it only
95 contains a CNAME while we are looking for a T_A or T_AAAA record,
96 we fail with NOTFOUND instead of TRYAGAIN. */
97- return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;
98+ if (canon != NULL)
99+ {
100+ *h_errnop = HOST_NOT_FOUND;
101+ return NSS_STATUS_NOTFOUND;
102+ }
103+
104+ *h_errnop = NETDB_INTERNAL;
105+ return NSS_STATUS_TRYAGAIN;
106 }
107
108
109@@ -1222,11 +1232,101 @@
110
111 enum nss_status status = NSS_STATUS_NOTFOUND;
112
113+ /* Combining the NSS status of two distinct queries requires some
114+ compromise and attention to symmetry (A or AAAA queries can be
115+ returned in any order). What follows is a breakdown of how this
116+ code is expected to work and why. We discuss only SUCCESS,
117+ TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns
118+ that apply (though RETURN and MERGE exist). We make a distinction
119+ between TRYAGAIN (recoverable) and TRYAGAIN' (not-recoverable).
120+ A recoverable TRYAGAIN is almost always due to buffer size issues
121+ and returns ERANGE in errno and the caller is expected to retry
122+ with a larger buffer.
123+
124+ Lastly, you may be tempted to make significant changes to the
125+ conditions in this code to bring about symmetry between responses.
126+ Please don't change anything without due consideration for
127+ expected application behaviour. Some of the synthesized responses
128+ aren't very well thought out and sometimes appear to imply that
129+ IPv4 responses are always answer 1, and IPv6 responses are always
130+ answer 2, but that's not true (see the implementation of send_dg
131+ and send_vc to see response can arrive in any order, particularly
132+ for UDP). However, we expect it holds roughly enough of the time
133+ that this code works, but certainly needs to be fixed to make this
134+ a more robust implementation.
135+
136+ ----------------------------------------------
137+ | Answer 1 Status / | Synthesized | Reason |
138+ | Answer 2 Status | Status | |
139+ |--------------------------------------------|
140+ | SUCCESS/SUCCESS | SUCCESS | [1] |
141+ | SUCCESS/TRYAGAIN | TRYAGAIN | [5] |
142+ | SUCCESS/TRYAGAIN' | SUCCESS | [1] |
143+ | SUCCESS/NOTFOUND | SUCCESS | [1] |
144+ | SUCCESS/UNAVAIL | SUCCESS | [1] |
145+ | TRYAGAIN/SUCCESS | TRYAGAIN | [2] |
146+ | TRYAGAIN/TRYAGAIN | TRYAGAIN | [2] |
147+ | TRYAGAIN/TRYAGAIN' | TRYAGAIN | [2] |
148+ | TRYAGAIN/NOTFOUND | TRYAGAIN | [2] |
149+ | TRYAGAIN/UNAVAIL | TRYAGAIN | [2] |
150+ | TRYAGAIN'/SUCCESS | SUCCESS | [3] |
151+ | TRYAGAIN'/TRYAGAIN | TRYAGAIN | [3] |
152+ | TRYAGAIN'/TRYAGAIN' | TRYAGAIN' | [3] |
153+ | TRYAGAIN'/NOTFOUND | TRYAGAIN' | [3] |
154+ | TRYAGAIN'/UNAVAIL | UNAVAIL | [3] |
155+ | NOTFOUND/SUCCESS | SUCCESS | [3] |
156+ | NOTFOUND/TRYAGAIN | TRYAGAIN | [3] |
157+ | NOTFOUND/TRYAGAIN' | TRYAGAIN' | [3] |
158+ | NOTFOUND/NOTFOUND | NOTFOUND | [3] |
159+ | NOTFOUND/UNAVAIL | UNAVAIL | [3] |
160+ | UNAVAIL/SUCCESS | UNAVAIL | [4] |
161+ | UNAVAIL/TRYAGAIN | UNAVAIL | [4] |
162+ | UNAVAIL/TRYAGAIN' | UNAVAIL | [4] |
163+ | UNAVAIL/NOTFOUND | UNAVAIL | [4] |
164+ | UNAVAIL/UNAVAIL | UNAVAIL | [4] |
165+ ----------------------------------------------
166+
167+ [1] If the first response is a success we return success.
168+ This ignores the state of the second answer and in fact
169+ incorrectly sets errno and h_errno to that of the second
170+ answer. However because the response is a success we ignore
171+ *errnop and *h_errnop (though that means you touched errno on
172+ success). We are being conservative here and returning the
173+ likely IPv4 response in the first answer as a success.
174+
175+ [2] If the first response is a recoverable TRYAGAIN we return
176+ that instead of looking at the second response. The
177+ expectation here is that we have failed to get an IPv4 response
178+ and should retry both queries.
179+
180+ [3] If the first response was not a SUCCESS and the second
181+ response is not NOTFOUND (had a SUCCESS, need to TRYAGAIN,
182+ or failed entirely e.g. TRYAGAIN' and UNAVAIL) then use the
183+ result from the second response, otherwise the first responses
184+ status is used. Again we have some odd side-effects when the
185+ second response is NOTFOUND because we overwrite *errnop and
186+ *h_errnop that means that a first answer of NOTFOUND might see
187+ its *errnop and *h_errnop values altered. Whether it matters
188+ in practice that a first response NOTFOUND has the wrong
189+ *errnop and *h_errnop is undecided.
190+
191+ [4] If the first response is UNAVAIL we return that instead of
192+ looking at the second response. The expectation here is that
193+ it will have failed similarly e.g. configuration failure.
194+
195+ [5] Testing this code is complicated by the fact that truncated
196+ second response buffers might be returned as SUCCESS if the
197+ first answer is a SUCCESS. To fix this we add symmetry to
198+ TRYAGAIN with the second response. If the second response
199+ is a recoverable error we now return TRYAGIN even if the first
200+ response was SUCCESS. */
201+
202 if (anslen1 > 0)
203 status = gaih_getanswer_slice(answer1, anslen1, qname,
204 &pat, &buffer, &buflen,
205 errnop, h_errnop, ttlp,
206 &first);
207+
208 if ((status == NSS_STATUS_SUCCESS || status == NSS_STATUS_NOTFOUND
209 || (status == NSS_STATUS_TRYAGAIN
210 /* We want to look at the second answer in case of an
211@@ -1242,8 +1342,15 @@
212 &pat, &buffer, &buflen,
213 errnop, h_errnop, ttlp,
214 &first);
215+ /* Use the second response status in some cases. */
216 if (status != NSS_STATUS_SUCCESS && status2 != NSS_STATUS_NOTFOUND)
217 status = status2;
218+ /* Do not return a truncated second response (unless it was
219+ unavoidable e.g. unrecoverable TRYAGAIN). */
220+ if (status == NSS_STATUS_SUCCESS
221+ && (status2 == NSS_STATUS_TRYAGAIN
222+ && *errnop == ERANGE && *h_errnop != NO_RECOVERY))
223+ status = NSS_STATUS_TRYAGAIN;
224 }
225
226 return status;
227diff -ruN a/resolv/res_query.c b/resolv/res_query.c
228--- a/resolv/res_query.c 2016-02-26 07:46:55.152904225 +0100
229+++ b/resolv/res_query.c 2016-02-26 07:48:34.137360778 +0100
230@@ -396,6 +396,7 @@
231 {
232 free (*answerp2);
233 *answerp2 = NULL;
234+ *nanswerp2 = 0;
235 *answerp2_malloced = 0;
236 }
237 }
238@@ -436,6 +437,7 @@
239 {
240 free (*answerp2);
241 *answerp2 = NULL;
242+ *nanswerp2 = 0;
243 *answerp2_malloced = 0;
244 }
245
246@@ -510,6 +512,7 @@
247 {
248 free (*answerp2);
249 *answerp2 = NULL;
250+ *nanswerp2 = 0;
251 *answerp2_malloced = 0;
252 }
253 if (saved_herrno != -1)
254diff -ruN a/resolv/res_send.c b/resolv/res_send.c
255--- a/resolv/res_send.c 2016-02-26 07:46:55.152904225 +0100
256+++ b/resolv/res_send.c 2016-02-26 07:55:48.240277574 +0100
257@@ -1,3 +1,20 @@
258+/* Copyright (C) 2016 Free Software Foundation, Inc.
259+ This file is part of the GNU C Library.
260+
261+ The GNU C Library is free software; you can redistribute it and/or
262+ modify it under the terms of the GNU Lesser General Public
263+ License as published by the Free Software Foundation; either
264+ version 2.1 of the License, or (at your option) any later version.
265+
266+ The GNU C Library is distributed in the hope that it will be useful,
267+ but WITHOUT ANY WARRANTY; without even the implied warranty of
268+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
269+ Lesser General Public License for more details.
270+
271+ You should have received a copy of the GNU Lesser General Public
272+ License along with the GNU C Library; if not, see
273+ <http://www.gnu.org/licenses/>. */
274+
275 /*
276 * Copyright (c) 1985, 1989, 1993
277 * The Regents of the University of California. All rights reserved.
278@@ -360,6 +377,8 @@
279 #ifdef USE_HOOKS
280 if (__glibc_unlikely (statp->qhook || statp->rhook)) {
281 if (anssiz < MAXPACKET && ansp) {
282+ /* Always allocate MAXPACKET, callers expect
283+ this specific size. */
284 u_char *buf = malloc (MAXPACKET);
285 if (buf == NULL)
286 return (-1);
287@@ -653,6 +672,77 @@
288
289 /* Private */
290
291+/* The send_vc function is responsible for sending a DNS query over TCP
292+ to the nameserver numbered NS from the res_state STATP i.e.
293+ EXT(statp).nssocks[ns]. The function supports sending both IPv4 and
294+ IPv6 queries at the same serially on the same socket.
295+
296+ Please note that for TCP there is no way to disable sending both
297+ queries, unlike UDP, which honours RES_SNGLKUP and RES_SNGLKUPREOP
298+ and sends the queries serially and waits for the result after each
299+ sent query. This implemetnation should be corrected to honour these
300+ options.
301+
302+ Please also note that for TCP we send both queries over the same
303+ socket one after another. This technically violates best practice
304+ since the server is allowed to read the first query, respond, and
305+ then close the socket (to service another client). If the server
306+ does this, then the remaining second query in the socket data buffer
307+ will cause the server to send the client an RST which will arrive
308+ asynchronously and the client's OS will likely tear down the socket
309+ receive buffer resulting in a potentially short read and lost
310+ response data. This will force the client to retry the query again,
311+ and this process may repeat until all servers and connection resets
312+ are exhausted and then the query will fail. It's not known if this
313+ happens with any frequency in real DNS server implementations. This
314+ implementation should be corrected to use two sockets by default for
315+ parallel queries.
316+
317+ The query stored in BUF of BUFLEN length is sent first followed by
318+ the query stored in BUF2 of BUFLEN2 length. Queries are sent
319+ serially on the same socket.
320+
321+ Answers to the query are stored firstly in *ANSP up to a max of
322+ *ANSSIZP bytes. If more than *ANSSIZP bytes are needed and ANSCP
323+ is non-NULL (to indicate that modifying the answer buffer is allowed)
324+ then malloc is used to allocate a new response buffer and ANSCP and
325+ ANSP will both point to the new buffer. If more than *ANSSIZP bytes
326+ are needed but ANSCP is NULL, then as much of the response as
327+ possible is read into the buffer, but the results will be truncated.
328+ When truncation happens because of a small answer buffer the DNS
329+ packets header field TC will bet set to 1, indicating a truncated
330+ message and the rest of the socket data will be read and discarded.
331+
332+ Answers to the query are stored secondly in *ANSP2 up to a max of
333+ *ANSSIZP2 bytes, with the actual response length stored in
334+ *RESPLEN2. If more than *ANSSIZP bytes are needed and ANSP2
335+ is non-NULL (required for a second query) then malloc is used to
336+ allocate a new response buffer, *ANSSIZP2 is set to the new buffer
337+ size and *ANSP2_MALLOCED is set to 1.
338+
339+ The ANSP2_MALLOCED argument will eventually be removed as the
340+ change in buffer pointer can be used to detect the buffer has
341+ changed and that the caller should use free on the new buffer.
342+
343+ Note that the answers may arrive in any order from the server and
344+ therefore the first and second answer buffers may not correspond to
345+ the first and second queries.
346+
347+ It is not supported to call this function with a non-NULL ANSP2
348+ but a NULL ANSCP. Put another way, you can call send_vc with a
349+ single unmodifiable buffer or two modifiable buffers, but no other
350+ combination is supported.
351+
352+ It is the caller's responsibility to free the malloc allocated
353+ buffers by detecting that the pointers have changed from their
354+ original values i.e. *ANSCP or *ANSP2 has changed.
355+
356+ If errors are encountered then *TERRNO is set to an appropriate
357+ errno value and a zero result is returned for a recoverable error,
358+ and a less-than zero result is returned for a non-recoverable error.
359+
360+ If no errors are encountered then *TERRNO is left unmodified and
361+ a the length of the first response in bytes is returned. */
362 static int
363 send_vc(res_state statp,
364 const u_char *buf, int buflen, const u_char *buf2, int buflen2,
365@@ -662,11 +752,7 @@
366 {
367 const HEADER *hp = (HEADER *) buf;
368 const HEADER *hp2 = (HEADER *) buf2;
369- u_char *ans = *ansp;
370- int orig_anssizp = *anssizp;
371- // XXX REMOVE
372- // int anssiz = *anssizp;
373- HEADER *anhp = (HEADER *) ans;
374+ HEADER *anhp = (HEADER *) *ansp;
375 struct sockaddr_in6 *nsap = EXT(statp).nsaddrs[ns];
376 int truncating, connreset, resplen, n;
377 struct iovec iov[4];
378@@ -742,6 +828,8 @@
379 * Receive length & response
380 */
381 int recvresp1 = 0;
382+ /* Skip the second response if there is no second query.
383+ To do that we mark the second response as received. */
384 int recvresp2 = buf2 == NULL;
385 uint16_t rlen16;
386 read_len:
387@@ -778,33 +866,14 @@
388 u_char **thisansp;
389 int *thisresplenp;
390 if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {
391+ /* We have not received any responses
392+ yet or we only have one response to
393+ receive. */
394 thisanssizp = anssizp;
395 thisansp = anscp ?: ansp;
396 assert (anscp != NULL || ansp2 == NULL);
397 thisresplenp = &resplen;
398 } else {
399- if (*anssizp != MAXPACKET) {
400- /* No buffer allocated for the first
401- reply. We can try to use the rest
402- of the user-provided buffer. */
403-#if _STRING_ARCH_unaligned
404- *anssizp2 = orig_anssizp - resplen;
405- *ansp2 = *ansp + resplen;
406-#else
407- int aligned_resplen
408- = ((resplen + __alignof__ (HEADER) - 1)
409- & ~(__alignof__ (HEADER) - 1));
410- *anssizp2 = orig_anssizp - aligned_resplen;
411- *ansp2 = *ansp + aligned_resplen;
412-#endif
413- } else {
414- /* The first reply did not fit into the
415- user-provided buffer. Maybe the second
416- answer will. */
417- *anssizp2 = orig_anssizp;
418- *ansp2 = *ansp;
419- }
420-
421 thisanssizp = anssizp2;
422 thisansp = ansp2;
423 thisresplenp = resplen2;
424@@ -812,10 +881,14 @@
425 anhp = (HEADER *) *thisansp;
426
427 *thisresplenp = rlen;
428- if (rlen > *thisanssizp) {
429- /* Yes, we test ANSCP here. If we have two buffers
430- both will be allocatable. */
431- if (__glibc_likely (anscp != NULL)) {
432+ /* Is the answer buffer too small? */
433+ if (*thisanssizp < rlen) {
434+ /* If the current buffer is not the the static
435+ user-supplied buffer then we can reallocate
436+ it. */
437+ if (thisansp != NULL && thisansp != ansp) {
438+ /* Always allocate MAXPACKET, callers expect
439+ this specific size. */
440 u_char *newp = malloc (MAXPACKET);
441 if (newp == NULL) {
442 *terrno = ENOMEM;
443@@ -827,6 +900,9 @@
444 if (thisansp == ansp2)
445 *ansp2_malloced = 1;
446 anhp = (HEADER *) newp;
447+ /* A uint16_t can't be larger than MAXPACKET
448+ thus it's safe to allocate MAXPACKET but
449+ read RLEN bytes instead. */
450 len = rlen;
451 } else {
452 Dprint(statp->options & RES_DEBUG,
453@@ -990,6 +1066,66 @@
454 return 1;
455 }
456
457+/* The send_dg function is responsible for sending a DNS query over UDP
458+ to the nameserver numbered NS from the res_state STATP i.e.
459+ EXT(statp).nssocks[ns]. The function supports IPv4 and IPv6 queries
460+ along with the ability to send the query in parallel for both stacks
461+ (default) or serially (RES_SINGLKUP). It also supports serial lookup
462+ with a close and reopen of the socket used to talk to the server
463+ (RES_SNGLKUPREOP) to work around broken name servers.
464+
465+ The query stored in BUF of BUFLEN length is sent first followed by
466+ the query stored in BUF2 of BUFLEN2 length. Queries are sent
467+ in parallel (default) or serially (RES_SINGLKUP or RES_SNGLKUPREOP).
468+
469+ Answers to the query are stored firstly in *ANSP up to a max of
470+ *ANSSIZP bytes. If more than *ANSSIZP bytes are needed and ANSCP
471+ is non-NULL (to indicate that modifying the answer buffer is allowed)
472+ then malloc is used to allocate a new response buffer and ANSCP and
473+ ANSP will both point to the new buffer. If more than *ANSSIZP bytes
474+ are needed but ANSCP is NULL, then as much of the response as
475+ possible is read into the buffer, but the results will be truncated.
476+ When truncation happens because of a small answer buffer the DNS
477+ packets header field TC will bet set to 1, indicating a truncated
478+ message, while the rest of the UDP packet is discarded.
479+
480+ Answers to the query are stored secondly in *ANSP2 up to a max of
481+ *ANSSIZP2 bytes, with the actual response length stored in
482+ *RESPLEN2. If more than *ANSSIZP bytes are needed and ANSP2
483+ is non-NULL (required for a second query) then malloc is used to
484+ allocate a new response buffer, *ANSSIZP2 is set to the new buffer
485+ size and *ANSP2_MALLOCED is set to 1.
486+
487+ The ANSP2_MALLOCED argument will eventually be removed as the
488+ change in buffer pointer can be used to detect the buffer has
489+ changed and that the caller should use free on the new buffer.
490+
491+ Note that the answers may arrive in any order from the server and
492+ therefore the first and second answer buffers may not correspond to
493+ the first and second queries.
494+
495+ It is not supported to call this function with a non-NULL ANSP2
496+ but a NULL ANSCP. Put another way, you can call send_vc with a
497+ single unmodifiable buffer or two modifiable buffers, but no other
498+ combination is supported.
499+
500+ It is the caller's responsibility to free the malloc allocated
501+ buffers by detecting that the pointers have changed from their
502+ original values i.e. *ANSCP or *ANSP2 has changed.
503+
504+ If an answer is truncated because of UDP datagram DNS limits then
505+ *V_CIRCUIT is set to 1 and the return value non-zero to indicate to
506+ the caller to retry with TCP. The value *GOTSOMEWHERE is set to 1
507+ if any progress was made reading a response from the nameserver and
508+ is used by the caller to distinguish between ECONNREFUSED and
509+ ETIMEDOUT (the latter if *GOTSOMEWHERE is 1).
510+
511+ If errors are encountered then *TERRNO is set to an appropriate
512+ errno value and a zero result is returned for a recoverable error,
513+ and a less-than zero result is returned for a non-recoverable error.
514+
515+ If no errors are encountered then *TERRNO is left unmodified and
516+ a the length of the first response in bytes is returned. */
517 static int
518 send_dg(res_state statp,
519 const u_char *buf, int buflen, const u_char *buf2, int buflen2,
520@@ -999,8 +1135,6 @@
521 {
522 const HEADER *hp = (HEADER *) buf;
523 const HEADER *hp2 = (HEADER *) buf2;
524- u_char *ans = *ansp;
525- int orig_anssizp = *anssizp;
526 struct timespec now, timeout, finish;
527 struct pollfd pfd[1];
528 int ptimeout;
529@@ -1033,6 +1167,8 @@
530 int need_recompute = 0;
531 int nwritten = 0;
532 int recvresp1 = 0;
533+ /* Skip the second response if there is no second query.
534+ To do that we mark the second response as received. */
535 int recvresp2 = buf2 == NULL;
536 pfd[0].fd = EXT(statp).nssocks[ns];
537 pfd[0].events = POLLOUT;
538@@ -1196,55 +1332,56 @@
539 int *thisresplenp;
540
541 if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {
542+ /* We have not received any responses
543+ yet or we only have one response to
544+ receive. */
545 thisanssizp = anssizp;
546 thisansp = anscp ?: ansp;
547 assert (anscp != NULL || ansp2 == NULL);
548 thisresplenp = &resplen;
549 } else {
550- if (*anssizp != MAXPACKET) {
551- /* No buffer allocated for the first
552- reply. We can try to use the rest
553- of the user-provided buffer. */
554-#if _STRING_ARCH_unaligned
555- *anssizp2 = orig_anssizp - resplen;
556- *ansp2 = *ansp + resplen;
557-#else
558- int aligned_resplen
559- = ((resplen + __alignof__ (HEADER) - 1)
560- & ~(__alignof__ (HEADER) - 1));
561- *anssizp2 = orig_anssizp - aligned_resplen;
562- *ansp2 = *ansp + aligned_resplen;
563-#endif
564- } else {
565- /* The first reply did not fit into the
566- user-provided buffer. Maybe the second
567- answer will. */
568- *anssizp2 = orig_anssizp;
569- *ansp2 = *ansp;
570- }
571-
572 thisanssizp = anssizp2;
573 thisansp = ansp2;
574 thisresplenp = resplen2;
575 }
576
577 if (*thisanssizp < MAXPACKET
578- /* Yes, we test ANSCP here. If we have two buffers
579- both will be allocatable. */
580- && anscp
581+ /* If the current buffer is not the the static
582+ user-supplied buffer then we can reallocate
583+ it. */
584+ && (thisansp != NULL && thisansp != ansp)
585 #ifdef FIONREAD
586+ /* Is the size too small? */
587 && (ioctl (pfd[0].fd, FIONREAD, thisresplenp) < 0
588 || *thisanssizp < *thisresplenp)
589 #endif
590 ) {
591+ /* Always allocate MAXPACKET, callers expect
592+ this specific size. */
593 u_char *newp = malloc (MAXPACKET);
594 if (newp != NULL) {
595- *anssizp = MAXPACKET;
596- *thisansp = ans = newp;
597+ *thisanssizp = MAXPACKET;
598+ *thisansp = newp;
599 if (thisansp == ansp2)
600 *ansp2_malloced = 1;
601 }
602 }
603+ /* We could end up with truncation if anscp was NULL
604+ (not allowed to change caller's buffer) and the
605+ response buffer size is too small. This isn't a
606+ reliable way to detect truncation because the ioctl
607+ may be an inaccurate report of the UDP message size.
608+ Therefore we use this only to issue debug output.
609+ To do truncation accurately with UDP we need
610+ MSG_TRUNC which is only available on Linux. We
611+ can abstract out the Linux-specific feature in the
612+ future to detect truncation. */
613+ if (__glibc_unlikely (*thisanssizp < *thisresplenp)) {
614+ Dprint(statp->options & RES_DEBUG,
615+ (stdout, ";; response may be truncated (UDP)\n")
616+ );
617+ }
618+
619 HEADER *anhp = (HEADER *) *thisansp;
620 socklen_t fromlen = sizeof(struct sockaddr_in6);
621 assert (sizeof(from) <= fromlen);
diff --git a/meta/recipes-core/glibc/glibc_2.20.bb b/meta/recipes-core/glibc/glibc_2.20.bb
index b854ea2..7af7502 100644
--- a/meta/recipes-core/glibc/glibc_2.20.bb
+++ b/meta/recipes-core/glibc/glibc_2.20.bb
@@ -55,6 +55,7 @@ CVEPATCHES = "\
55 file://CVE-2015-8777.patch \ 55 file://CVE-2015-8777.patch \
56 file://CVE-2015-8778.patch \ 56 file://CVE-2015-8778.patch \
57 file://CVE-2015-8779.patch \ 57 file://CVE-2015-8779.patch \
58 file://CVE-2015-7547.patch \
58 " 59 "
59LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \ 60LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
60 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ 61 file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \