<p dir="ltr">This is an important fix. Looks good to me</p>
<div class="gmail_quote">On Apr 6, 2016 5:35 AM, &quot;Javier Viguera&quot; &lt;<a href="mailto:javier.viguera@digi.com">javier.viguera@digi.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">CVE-2015-7547: getaddrinfo() stack-based buffer overflow<br>
<br>
Backport patch from GLIBC-2.20 to EGLIBC-2.19.<br>
<br>
Signed-off-by: Javier Viguera &lt;<a href="mailto:javier.viguera@digi.com">javier.viguera@digi.com</a>&gt;<br>
---<br>
 .../eglibc/eglibc-2.19/CVE-2015-7547.patch         | 585 +++++++++++++++++++++<br>
 meta/recipes-core/eglibc/<a href="http://eglibc_2.19.bb" rel="noreferrer" target="_blank">eglibc_2.19.bb</a>            |   1 +<br>
 2 files changed, 586 insertions(+)<br>
 create mode 100644 meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch<br>
<br>
diff --git a/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch b/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch<br>
new file mode 100644<br>
index 000000000000..2a52e56cb7f4<br>
--- /dev/null<br>
+++ b/meta/recipes-core/eglibc/eglibc-2.19/CVE-2015-7547.patch<br>
@@ -0,0 +1,585 @@<br>
+From: Carlos O&#39;Donell &lt;<a href="mailto:carlos@systemhalted.org">carlos@systemhalted.org</a>&gt;<br>
+Date: Tue, 16 Feb 2016 21:26:37 -0500<br>
+Subject: [PATCH] CVE-2015-7547: getaddrinfo() stack-based buffer overflow (Bug<br>
+ 18665).<br>
+<br>
+* A stack-based buffer overflow was found in libresolv when invoked from<br>
+  libnss_dns, allowing specially crafted DNS responses to seize control<br>
+  of execution flow in the DNS client.  The buffer overflow occurs in<br>
+  the functions send_dg (send datagram) and send_vc (send TCP) for the<br>
+  NSS module libnss_dns.so.2 when calling getaddrinfo with AF_UNSPEC<br>
+  family.  The use of AF_UNSPEC triggers the low-level resolver code to<br>
+  send out two parallel queries for A and AAAA.  A mismanagement of the<br>
+  buffers used for those queries could result in the response of a query<br>
+  writing beyond the alloca allocated buffer created by<br>
+  _nss_dns_gethostbyname4_r.  Buffer management is simplified to remove<br>
+  the overflow.  Thanks to the Google Security Team and Red Hat for<br>
+  reporting the security impact of this issue, and Robert Holiday of<br>
+  Ciena for reporting the related bug 18665. (CVE-2015-7547)<br>
+<br>
+See also:<br>
+<a href="https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html</a><br>
+<a href="https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html" rel="noreferrer" target="_blank">https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html</a><br>
+<br>
+Upstream-Status: Backport<br>
+CVE: CVE-2015-7547<br>
+<br>
+Upstream commit:<br>
+<a href="https://sourceware.org/git/?p=glibc.git;a=commit;h=16d0a0ce7613552301786bf05d7eba8784b5732c" rel="noreferrer" target="_blank">https://sourceware.org/git/?p=glibc.git;a=commit;h=16d0a0ce7613552301786bf05d7eba8784b5732c</a><br>
+<br>
+Tweaks:<br>
+* Adapted from GLIBC-2.20 to EGLIBC-2.19<br>
+* Removed changes to ChangeLog and NEWS files<br>
+<br>
+Signed-off-by: Javier Viguera &lt;<a href="mailto:javier.viguera@digi.com">javier.viguera@digi.com</a>&gt;<br>
+---<br>
+ resolv/nss_dns/dns-host.c | 111 +++++++++++++++++++-<br>
+ resolv/res_query.c        |   3 +<br>
+ resolv/res_send.c         | 257 +++++++++++++++++++++++++++++++++++-----------<br>
+ 3 files changed, 309 insertions(+), 62 deletions(-)<br>
+<br>
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c<br>
+index f8f192e5afb5..e7e2c7137a50 100644<br>
+--- a/resolv/nss_dns/dns-host.c<br>
++++ b/resolv/nss_dns/dns-host.c<br>
+@@ -1049,7 +1049,10 @@ gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname,<br>
+   int h_namelen = 0;<br>
+<br>
+   if (ancount == 0)<br>
+-    return NSS_STATUS_NOTFOUND;<br>
++    {<br>
++      *h_errnop = HOST_NOT_FOUND;<br>
++      return NSS_STATUS_NOTFOUND;<br>
++    }<br>
+<br>
+   while (ancount-- &gt; 0 &amp;&amp; cp &lt; end_of_message &amp;&amp; had_error == 0)<br>
+     {<br>
+@@ -1226,7 +1229,14 @@ gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname,<br>
+   /* Special case here: if the resolver sent a result but it only<br>
+      contains a CNAME while we are looking for a T_A or T_AAAA record,<br>
+      we fail with NOTFOUND instead of TRYAGAIN.  */<br>
+-  return canon == NULL ? NSS_STATUS_TRYAGAIN : NSS_STATUS_NOTFOUND;<br>
++  if (canon != NULL)<br>
++    {<br>
++      *h_errnop = HOST_NOT_FOUND;<br>
++      return NSS_STATUS_NOTFOUND;<br>
++    }<br>
++<br>
++  *h_errnop = NETDB_INTERNAL;<br>
++  return NSS_STATUS_TRYAGAIN;<br>
+ }<br>
+<br>
+<br>
+@@ -1240,11 +1250,101 @@ gaih_getanswer (const querybuf *answer1, int anslen1, const querybuf *answer2,<br>
+<br>
+   enum nss_status status = NSS_STATUS_NOTFOUND;<br>
+<br>
++  /* Combining the NSS status of two distinct queries requires some<br>
++     compromise and attention to symmetry (A or AAAA queries can be<br>
++     returned in any order).  What follows is a breakdown of how this<br>
++     code is expected to work and why. We discuss only SUCCESS,<br>
++     TRYAGAIN, NOTFOUND and UNAVAIL, since they are the only returns<br>
++     that apply (though RETURN and MERGE exist).  We make a distinction<br>
++     between TRYAGAIN (recoverable) and TRYAGAIN&#39; (not-recoverable).<br>
++     A recoverable TRYAGAIN is almost always due to buffer size issues<br>
++     and returns ERANGE in errno and the caller is expected to retry<br>
++     with a larger buffer.<br>
++<br>
++     Lastly, you may be tempted to make significant changes to the<br>
++     conditions in this code to bring about symmetry between responses.<br>
++     Please don&#39;t change anything without due consideration for<br>
++     expected application behaviour.  Some of the synthesized responses<br>
++     aren&#39;t very well thought out and sometimes appear to imply that<br>
++     IPv4 responses are always answer 1, and IPv6 responses are always<br>
++     answer 2, but that&#39;s not true (see the implementation of send_dg<br>
++     and send_vc to see response can arrive in any order, particularly<br>
++     for UDP). However, we expect it holds roughly enough of the time<br>
++     that this code works, but certainly needs to be fixed to make this<br>
++     a more robust implementation.<br>
++<br>
++     ----------------------------------------------<br>
++     | Answer 1 Status /   | Synthesized | Reason |<br>
++     | Answer 2 Status     | Status      |        |<br>
++     |--------------------------------------------|<br>
++     | SUCCESS/SUCCESS     | SUCCESS     | [1]    |<br>
++     | SUCCESS/TRYAGAIN    | TRYAGAIN    | [5]    |<br>
++     | SUCCESS/TRYAGAIN&#39;   | SUCCESS     | [1]    |<br>
++     | SUCCESS/NOTFOUND    | SUCCESS     | [1]    |<br>
++     | SUCCESS/UNAVAIL     | SUCCESS     | [1]    |<br>
++     | TRYAGAIN/SUCCESS    | TRYAGAIN    | [2]    |<br>
++     | TRYAGAIN/TRYAGAIN   | TRYAGAIN    | [2]    |<br>
++     | TRYAGAIN/TRYAGAIN&#39;  | TRYAGAIN    | [2]    |<br>
++     | TRYAGAIN/NOTFOUND   | TRYAGAIN    | [2]    |<br>
++     | TRYAGAIN/UNAVAIL    | TRYAGAIN    | [2]    |<br>
++     | TRYAGAIN&#39;/SUCCESS   | SUCCESS     | [3]    |<br>
++     | TRYAGAIN&#39;/TRYAGAIN  | TRYAGAIN    | [3]    |<br>
++     | TRYAGAIN&#39;/TRYAGAIN&#39; | TRYAGAIN&#39;   | [3]    |<br>
++     | TRYAGAIN&#39;/NOTFOUND  | TRYAGAIN&#39;   | [3]    |<br>
++     | TRYAGAIN&#39;/UNAVAIL   | UNAVAIL     | [3]    |<br>
++     | NOTFOUND/SUCCESS    | SUCCESS     | [3]    |<br>
++     | NOTFOUND/TRYAGAIN   | TRYAGAIN    | [3]    |<br>
++     | NOTFOUND/TRYAGAIN&#39;  | TRYAGAIN&#39;   | [3]    |<br>
++     | NOTFOUND/NOTFOUND   | NOTFOUND    | [3]    |<br>
++     | NOTFOUND/UNAVAIL    | UNAVAIL     | [3]    |<br>
++     | UNAVAIL/SUCCESS     | UNAVAIL     | [4]    |<br>
++     | UNAVAIL/TRYAGAIN    | UNAVAIL     | [4]    |<br>
++     | UNAVAIL/TRYAGAIN&#39;   | UNAVAIL     | [4]    |<br>
++     | UNAVAIL/NOTFOUND    | UNAVAIL     | [4]    |<br>
++     | UNAVAIL/UNAVAIL     | UNAVAIL     | [4]    |<br>
++     ----------------------------------------------<br>
++<br>
++     [1] If the first response is a success we return success.<br>
++       This ignores the state of the second answer and in fact<br>
++       incorrectly sets errno and h_errno to that of the second<br>
++       answer.  However because the response is a success we ignore<br>
++       *errnop and *h_errnop (though that means you touched errno on<br>
++       success).  We are being conservative here and returning the<br>
++       likely IPv4 response in the first answer as a success.<br>
++<br>
++     [2] If the first response is a recoverable TRYAGAIN we return<br>
++       that instead of looking at the second response.  The<br>
++       expectation here is that we have failed to get an IPv4 response<br>
++       and should retry both queries.<br>
++<br>
++     [3] If the first response was not a SUCCESS and the second<br>
++       response is not NOTFOUND (had a SUCCESS, need to TRYAGAIN,<br>
++       or failed entirely e.g. TRYAGAIN&#39; and UNAVAIL) then use the<br>
++       result from the second response, otherwise the first responses<br>
++       status is used.  Again we have some odd side-effects when the<br>
++       second response is NOTFOUND because we overwrite *errnop and<br>
++       *h_errnop that means that a first answer of NOTFOUND might see<br>
++       its *errnop and *h_errnop values altered.  Whether it matters<br>
++       in practice that a first response NOTFOUND has the wrong<br>
++       *errnop and *h_errnop is undecided.<br>
++<br>
++     [4] If the first response is UNAVAIL we return that instead of<br>
++       looking at the second response.  The expectation here is that<br>
++       it will have failed similarly e.g. configuration failure.<br>
++<br>
++     [5] Testing this code is complicated by the fact that truncated<br>
++       second response buffers might be returned as SUCCESS if the<br>
++       first answer is a SUCCESS.  To fix this we add symmetry to<br>
++       TRYAGAIN with the second response.  If the second response<br>
++       is a recoverable error we now return TRYAGIN even if the first<br>
++       response was SUCCESS.  */<br>
++<br>
+   if (anslen1 &gt; 0)<br>
+     status = gaih_getanswer_slice(answer1, anslen1, qname,<br>
+                                 &amp;pat, &amp;buffer, &amp;buflen,<br>
+                                 errnop, h_errnop, ttlp,<br>
+                                 &amp;first);<br>
++<br>
+   if ((status == NSS_STATUS_SUCCESS || status == NSS_STATUS_NOTFOUND<br>
+        || (status == NSS_STATUS_TRYAGAIN<br>
+          /* We want to look at the second answer in case of an<br>
+@@ -1260,8 +1360,15 @@ gaih_getanswer (const querybuf *answer1, int anslen1, const querybuf *answer2,<br>
+                                                    &amp;pat, &amp;buffer, &amp;buflen,<br>
+                                                    errnop, h_errnop, ttlp,<br>
+                                                    &amp;first);<br>
++      /* Use the second response status in some cases.  */<br>
+       if (status != NSS_STATUS_SUCCESS &amp;&amp; status2 != NSS_STATUS_NOTFOUND)<br>
+       status = status2;<br>
++      /* Do not return a truncated second response (unless it was<br>
++       unavoidable e.g. unrecoverable TRYAGAIN).  */<br>
++      if (status == NSS_STATUS_SUCCESS<br>
++        &amp;&amp; (status2 == NSS_STATUS_TRYAGAIN<br>
++            &amp;&amp; *errnop == ERANGE &amp;&amp; *h_errnop != NO_RECOVERY))<br>
++      status = NSS_STATUS_TRYAGAIN;<br>
+     }<br>
+<br>
+   return status;<br>
+diff --git a/resolv/res_query.c b/resolv/res_query.c<br>
+index 1325f9772ddc..dd87e097c461 100644<br>
+--- a/resolv/res_query.c<br>
++++ b/resolv/res_query.c<br>
+@@ -391,6 +391,7 @@ __libc_res_nsearch(res_state statp,<br>
+                 {<br>
+                   free (*answerp2);<br>
+                   *answerp2 = NULL;<br>
++                  *nanswerp2 = 0;<br>
+                 }<br>
+       }<br>
+<br>
+@@ -431,6 +432,7 @@ __libc_res_nsearch(res_state statp,<br>
+                         {<br>
+                           free (*answerp2);<br>
+                           *answerp2 = NULL;<br>
++                          *nanswerp2 = 0;<br>
+                         }<br>
+<br>
+                       /*<br>
+@@ -502,6 +504,7 @@ __libc_res_nsearch(res_state statp,<br>
+         {<br>
+           free (*answerp2);<br>
+           *answerp2 = NULL;<br>
++          *nanswerp2 = 0;<br>
+         }<br>
+       if (saved_herrno != -1)<br>
+               RES_SET_H_ERRNO(statp, saved_herrno);<br>
+diff --git a/resolv/res_send.c b/resolv/res_send.c<br>
+index 7f2e85f3240e..5940b0c7ebf7 100644<br>
+--- a/resolv/res_send.c<br>
++++ b/resolv/res_send.c<br>
+@@ -1,3 +1,20 @@<br>
++/* Copyright (C) 2016 Free Software Foundation, Inc.<br>
++   This file is part of the GNU C Library.<br>
++<br>
++   The GNU C Library is free software; you can redistribute it and/or<br>
++   modify it under the terms of the GNU Lesser General Public<br>
++   License as published by the Free Software Foundation; either<br>
++   version 2.1 of the License, or (at your option) any later version.<br>
++<br>
++   The GNU C Library is distributed in the hope that it will be useful,<br>
++   but WITHOUT ANY WARRANTY; without even the implied warranty of<br>
++   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU<br>
++   Lesser General Public License for more details.<br>
++<br>
++   You should have received a copy of the GNU Lesser General Public<br>
++   License along with the GNU C Library; if not, see<br>
++   &lt;<a href="http://www.gnu.org/licenses/" rel="noreferrer" target="_blank">http://www.gnu.org/licenses/</a>&gt;.  */<br>
++<br>
+ /*<br>
+  * Copyright (c) 1985, 1989, 1993<br>
+  *    The Regents of the University of California.  All rights reserved.<br>
+@@ -360,6 +377,8 @@ __libc_res_nsend(res_state statp, const u_char *buf, int buflen,<br>
+ #ifdef USE_HOOKS<br>
+       if (__builtin_expect (statp-&gt;qhook || statp-&gt;rhook, 0)) {<br>
+               if (anssiz &lt; MAXPACKET &amp;&amp; ansp) {<br>
++                      /* Always allocate MAXPACKET, callers expect<br>
++                         this specific size.  */<br>
+                       u_char *buf = malloc (MAXPACKET);<br>
+                       if (buf == NULL)<br>
+                               return (-1);<br>
+@@ -652,6 +671,77 @@ libresolv_hidden_def (res_nsend)<br>
+<br>
+ /* Private */<br>
+<br>
++/* The send_vc function is responsible for sending a DNS query over TCP<br>
++   to the nameserver numbered NS from the res_state STATP i.e.<br>
++   EXT(statp).nssocks[ns].  The function supports sending both IPv4 and<br>
++   IPv6 queries at the same serially on the same socket.<br>
++<br>
++   Please note that for TCP there is no way to disable sending both<br>
++   queries, unlike UDP, which honours RES_SNGLKUP and RES_SNGLKUPREOP<br>
++   and sends the queries serially and waits for the result after each<br>
++   sent query.  This implemetnation should be corrected to honour these<br>
++   options.<br>
++<br>
++   Please also note that for TCP we send both queries over the same<br>
++   socket one after another.  This technically violates best practice<br>
++   since the server is allowed to read the first query, respond, and<br>
++   then close the socket (to service another client).  If the server<br>
++   does this, then the remaining second query in the socket data buffer<br>
++   will cause the server to send the client an RST which will arrive<br>
++   asynchronously and the client&#39;s OS will likely tear down the socket<br>
++   receive buffer resulting in a potentially short read and lost<br>
++   response data.  This will force the client to retry the query again,<br>
++   and this process may repeat until all servers and connection resets<br>
++   are exhausted and then the query will fail.  It&#39;s not known if this<br>
++   happens with any frequency in real DNS server implementations.  This<br>
++   implementation should be corrected to use two sockets by default for<br>
++   parallel queries.<br>
++<br>
++   The query stored in BUF of BUFLEN length is sent first followed by<br>
++   the query stored in BUF2 of BUFLEN2 length.  Queries are sent<br>
++   serially on the same socket.<br>
++<br>
++   Answers to the query are stored firstly in *ANSP up to a max of<br>
++   *ANSSIZP bytes.  If more than *ANSSIZP bytes are needed and ANSCP<br>
++   is non-NULL (to indicate that modifying the answer buffer is allowed)<br>
++   then malloc is used to allocate a new response buffer and ANSCP and<br>
++   ANSP will both point to the new buffer.  If more than *ANSSIZP bytes<br>
++   are needed but ANSCP is NULL, then as much of the response as<br>
++   possible is read into the buffer, but the results will be truncated.<br>
++   When truncation happens because of a small answer buffer the DNS<br>
++   packets header field TC will bet set to 1, indicating a truncated<br>
++   message and the rest of the socket data will be read and discarded.<br>
++<br>
++   Answers to the query are stored secondly in *ANSP2 up to a max of<br>
++   *ANSSIZP2 bytes, with the actual response length stored in<br>
++   *RESPLEN2.  If more than *ANSSIZP bytes are needed and ANSP2<br>
++   is non-NULL (required for a second query) then malloc is used to<br>
++   allocate a new response buffer, *ANSSIZP2 is set to the new buffer<br>
++   size and *ANSP2_MALLOCED is set to 1.<br>
++<br>
++   The ANSP2_MALLOCED argument will eventually be removed as the<br>
++   change in buffer pointer can be used to detect the buffer has<br>
++   changed and that the caller should use free on the new buffer.<br>
++<br>
++   Note that the answers may arrive in any order from the server and<br>
++   therefore the first and second answer buffers may not correspond to<br>
++   the first and second queries.<br>
++<br>
++   It is not supported to call this function with a non-NULL ANSP2<br>
++   but a NULL ANSCP.  Put another way, you can call send_vc with a<br>
++   single unmodifiable buffer or two modifiable buffers, but no other<br>
++   combination is supported.<br>
++<br>
++   It is the caller&#39;s responsibility to free the malloc allocated<br>
++   buffers by detecting that the pointers have changed from their<br>
++   original values i.e. *ANSCP or *ANSP2 has changed.<br>
++<br>
++   If errors are encountered then *TERRNO is set to an appropriate<br>
++   errno value and a zero result is returned for a recoverable error,<br>
++   and a less-than zero result is returned for a non-recoverable error.<br>
++<br>
++   If no errors are encountered then *TERRNO is left unmodified and<br>
++   a the length of the first response in bytes is returned.  */<br>
+ static int<br>
+ send_vc(res_state statp,<br>
+       const u_char *buf, int buflen, const u_char *buf2, int buflen2,<br>
+@@ -661,11 +751,7 @@ send_vc(res_state statp,<br>
+ {<br>
+       const HEADER *hp = (HEADER *) buf;<br>
+       const HEADER *hp2 = (HEADER *) buf2;<br>
+-      u_char *ans = *ansp;<br>
+-      int orig_anssizp = *anssizp;<br>
+-      // XXX REMOVE<br>
+-      // int anssiz = *anssizp;<br>
+-      HEADER *anhp = (HEADER *) ans;<br>
++      HEADER *anhp = (HEADER *) *ansp;<br>
+       struct sockaddr_in6 *nsap = EXT(statp).nsaddrs[ns];<br>
+       int truncating, connreset, resplen, n;<br>
+       struct iovec iov[4];<br>
+@@ -741,6 +827,8 @@ send_vc(res_state statp,<br>
+        * Receive length &amp; response<br>
+        */<br>
+       int recvresp1 = 0;<br>
++      /* Skip the second response if there is no second query.<br>
++         To do that we mark the second response as received.  */<br>
+       int recvresp2 = buf2 == NULL;<br>
+       uint16_t rlen16;<br>
+  read_len:<br>
+@@ -777,33 +865,14 @@ send_vc(res_state statp,<br>
+       u_char **thisansp;<br>
+       int *thisresplenp;<br>
+       if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {<br>
++              /* We have not received any responses<br>
++                 yet or we only have one response to<br>
++                 receive.  */<br>
+               thisanssizp = anssizp;<br>
+               thisansp = anscp ?: ansp;<br>
+               assert (anscp != NULL || ansp2 == NULL);<br>
+               thisresplenp = &amp;resplen;<br>
+       } else {<br>
+-              if (*anssizp != MAXPACKET) {<br>
+-                      /* No buffer allocated for the first<br>
+-                         reply.  We can try to use the rest<br>
+-                         of the user-provided buffer.  */<br>
+-#ifdef _STRING_ARCH_unaligned<br>
+-                      *anssizp2 = orig_anssizp - resplen;<br>
+-                      *ansp2 = *ansp + resplen;<br>
+-#else<br>
+-                      int aligned_resplen<br>
+-                        = ((resplen + __alignof__ (HEADER) - 1)<br>
+-                           &amp; ~(__alignof__ (HEADER) - 1));<br>
+-                      *anssizp2 = orig_anssizp - aligned_resplen;<br>
+-                      *ansp2 = *ansp + aligned_resplen;<br>
+-#endif<br>
+-              } else {<br>
+-                      /* The first reply did not fit into the<br>
+-                         user-provided buffer.  Maybe the second<br>
+-                         answer will.  */<br>
+-                      *anssizp2 = orig_anssizp;<br>
+-                      *ansp2 = *ansp;<br>
+-              }<br>
+-<br>
+               thisanssizp = anssizp2;<br>
+               thisansp = ansp2;<br>
+               thisresplenp = resplen2;<br>
+@@ -811,10 +880,14 @@ send_vc(res_state statp,<br>
+       anhp = (HEADER *) *thisansp;<br>
+<br>
+       *thisresplenp = rlen;<br>
+-      if (rlen &gt; *thisanssizp) {<br>
+-              /* Yes, we test ANSCP here.  If we have two buffers<br>
+-                 both will be allocatable.  */<br>
+-              if (__builtin_expect (anscp != NULL, 1)) {<br>
++      /* Is the answer buffer too small?  */<br>
++      if (*thisanssizp &lt; rlen) {<br>
++              /* If the current buffer is not the the static<br>
++                 user-supplied buffer then we can reallocate<br>
++                 it.  */<br>
++              if (thisansp != NULL &amp;&amp; thisansp != ansp) {<br>
++                      /* Always allocate MAXPACKET, callers expect<br>
++                         this specific size.  */<br>
+                       u_char *newp = malloc (MAXPACKET);<br>
+                       if (newp == NULL) {<br>
+                               *terrno = ENOMEM;<br>
+@@ -824,6 +897,9 @@ send_vc(res_state statp,<br>
+                       *thisanssizp = MAXPACKET;<br>
+                       *thisansp = newp;<br>
+                       anhp = (HEADER *) newp;<br>
++                      /* A uint16_t can&#39;t be larger than MAXPACKET<br>
++                         thus it&#39;s safe to allocate MAXPACKET but<br>
++                         read RLEN bytes instead.  */<br>
+                       len = rlen;<br>
+               } else {<br>
+                       Dprint(statp-&gt;options &amp; RES_DEBUG,<br>
+@@ -987,6 +1063,66 @@ reopen (res_state statp, int *terrno, int ns)<br>
+       return 1;<br>
+ }<br>
+<br>
++/* The send_dg function is responsible for sending a DNS query over UDP<br>
++   to the nameserver numbered NS from the res_state STATP i.e.<br>
++   EXT(statp).nssocks[ns].  The function supports IPv4 and IPv6 queries<br>
++   along with the ability to send the query in parallel for both stacks<br>
++   (default) or serially (RES_SINGLKUP).  It also supports serial lookup<br>
++   with a close and reopen of the socket used to talk to the server<br>
++   (RES_SNGLKUPREOP) to work around broken name servers.<br>
++<br>
++   The query stored in BUF of BUFLEN length is sent first followed by<br>
++   the query stored in BUF2 of BUFLEN2 length.  Queries are sent<br>
++   in parallel (default) or serially (RES_SINGLKUP or RES_SNGLKUPREOP).<br>
++<br>
++   Answers to the query are stored firstly in *ANSP up to a max of<br>
++   *ANSSIZP bytes.  If more than *ANSSIZP bytes are needed and ANSCP<br>
++   is non-NULL (to indicate that modifying the answer buffer is allowed)<br>
++   then malloc is used to allocate a new response buffer and ANSCP and<br>
++   ANSP will both point to the new buffer.  If more than *ANSSIZP bytes<br>
++   are needed but ANSCP is NULL, then as much of the response as<br>
++   possible is read into the buffer, but the results will be truncated.<br>
++   When truncation happens because of a small answer buffer the DNS<br>
++   packets header field TC will bet set to 1, indicating a truncated<br>
++   message, while the rest of the UDP packet is discarded.<br>
++<br>
++   Answers to the query are stored secondly in *ANSP2 up to a max of<br>
++   *ANSSIZP2 bytes, with the actual response length stored in<br>
++   *RESPLEN2.  If more than *ANSSIZP bytes are needed and ANSP2<br>
++   is non-NULL (required for a second query) then malloc is used to<br>
++   allocate a new response buffer, *ANSSIZP2 is set to the new buffer<br>
++   size and *ANSP2_MALLOCED is set to 1.<br>
++<br>
++   The ANSP2_MALLOCED argument will eventually be removed as the<br>
++   change in buffer pointer can be used to detect the buffer has<br>
++   changed and that the caller should use free on the new buffer.<br>
++<br>
++   Note that the answers may arrive in any order from the server and<br>
++   therefore the first and second answer buffers may not correspond to<br>
++   the first and second queries.<br>
++<br>
++   It is not supported to call this function with a non-NULL ANSP2<br>
++   but a NULL ANSCP.  Put another way, you can call send_vc with a<br>
++   single unmodifiable buffer or two modifiable buffers, but no other<br>
++   combination is supported.<br>
++<br>
++   It is the caller&#39;s responsibility to free the malloc allocated<br>
++   buffers by detecting that the pointers have changed from their<br>
++   original values i.e. *ANSCP or *ANSP2 has changed.<br>
++<br>
++   If an answer is truncated because of UDP datagram DNS limits then<br>
++   *V_CIRCUIT is set to 1 and the return value non-zero to indicate to<br>
++   the caller to retry with TCP.  The value *GOTSOMEWHERE is set to 1<br>
++   if any progress was made reading a response from the nameserver and<br>
++   is used by the caller to distinguish between ECONNREFUSED and<br>
++   ETIMEDOUT (the latter if *GOTSOMEWHERE is 1).<br>
++<br>
++   If errors are encountered then *TERRNO is set to an appropriate<br>
++   errno value and a zero result is returned for a recoverable error,<br>
++   and a less-than zero result is returned for a non-recoverable error.<br>
++<br>
++   If no errors are encountered then *TERRNO is left unmodified and<br>
++   a the length of the first response in bytes is returned.  */<br>
+ static int<br>
+ send_dg(res_state statp,<br>
+       const u_char *buf, int buflen, const u_char *buf2, int buflen2,<br>
+@@ -996,8 +1132,6 @@ send_dg(res_state statp,<br>
+ {<br>
+       const HEADER *hp = (HEADER *) buf;<br>
+       const HEADER *hp2 = (HEADER *) buf2;<br>
+-      u_char *ans = *ansp;<br>
+-      int orig_anssizp = *anssizp;<br>
+       struct timespec now, timeout, finish;<br>
+       struct pollfd pfd[1];<br>
+       int ptimeout;<br>
+@@ -1030,6 +1164,8 @@ send_dg(res_state statp,<br>
+       int need_recompute = 0;<br>
+       int nwritten = 0;<br>
+       int recvresp1 = 0;<br>
++      /* Skip the second response if there is no second query.<br>
++         To do that we mark the second response as received.  */<br>
+       int recvresp2 = buf2 == NULL;<br>
+       pfd[0].fd = EXT(statp).nssocks[ns];<br>
+       pfd[0].events = POLLOUT;<br>
+@@ -1193,53 +1329,54 @@ send_dg(res_state statp,<br>
+               int *thisresplenp;<br>
+<br>
+               if ((recvresp1 | recvresp2) == 0 || buf2 == NULL) {<br>
++                      /* We have not received any responses<br>
++                         yet or we only have one response to<br>
++                         receive.  */<br>
+                       thisanssizp = anssizp;<br>
+                       thisansp = anscp ?: ansp;<br>
+                       assert (anscp != NULL || ansp2 == NULL);<br>
+                       thisresplenp = &amp;resplen;<br>
+               } else {<br>
+-                      if (*anssizp != MAXPACKET) {<br>
+-                              /* No buffer allocated for the first<br>
+-                                 reply.  We can try to use the rest<br>
+-                                 of the user-provided buffer.  */<br>
+-#ifdef _STRING_ARCH_unaligned<br>
+-                              *anssizp2 = orig_anssizp - resplen;<br>
+-                              *ansp2 = *ansp + resplen;<br>
+-#else<br>
+-                              int aligned_resplen<br>
+-                                = ((resplen + __alignof__ (HEADER) - 1)<br>
+-                                   &amp; ~(__alignof__ (HEADER) - 1));<br>
+-                              *anssizp2 = orig_anssizp - aligned_resplen;<br>
+-                              *ansp2 = *ansp + aligned_resplen;<br>
+-#endif<br>
+-                      } else {<br>
+-                              /* The first reply did not fit into the<br>
+-                                 user-provided buffer.  Maybe the second<br>
+-                                 answer will.  */<br>
+-                              *anssizp2 = orig_anssizp;<br>
+-                              *ansp2 = *ansp;<br>
+-                      }<br>
+-<br>
+                       thisanssizp = anssizp2;<br>
+                       thisansp = ansp2;<br>
+                       thisresplenp = resplen2;<br>
+               }<br>
+<br>
+               if (*thisanssizp &lt; MAXPACKET<br>
+-                  /* Yes, we test ANSCP here.  If we have two buffers<br>
+-                     both will be allocatable.  */<br>
+-                  &amp;&amp; anscp<br>
++                  /* If the current buffer is not the the static<br>
++                     user-supplied buffer then we can reallocate<br>
++                     it.  */<br>
++                  &amp;&amp; (thisansp != NULL &amp;&amp; thisansp != ansp)<br>
+ #ifdef FIONREAD<br>
++                  /* Is the size too small?  */<br>
+                   &amp;&amp; (ioctl (pfd[0].fd, FIONREAD, thisresplenp) &lt; 0<br>
+                       || *thisanssizp &lt; *thisresplenp)<br>
+ #endif<br>
+                     ) {<br>
++                      /* Always allocate MAXPACKET, callers expect<br>
++                         this specific size.  */<br>
+                       u_char *newp = malloc (MAXPACKET);<br>
+                       if (newp != NULL) {<br>
+-                              *anssizp = MAXPACKET;<br>
+-                              *thisansp = ans = newp;<br>
++                              *thisanssizp = MAXPACKET;<br>
++                              *thisansp = newp;<br>
+                       }<br>
+               }<br>
++              /* We could end up with truncation if anscp was NULL<br>
++                 (not allowed to change caller&#39;s buffer) and the<br>
++                 response buffer size is too small.  This isn&#39;t a<br>
++                 reliable way to detect truncation because the ioctl<br>
++                 may be an inaccurate report of the UDP message size.<br>
++                 Therefore we use this only to issue debug output.<br>
++                 To do truncation accurately with UDP we need<br>
++                 MSG_TRUNC which is only available on Linux.  We<br>
++                 can abstract out the Linux-specific feature in the<br>
++                 future to detect truncation.  */<br>
++              if (__glibc_unlikely (*thisanssizp &lt; *thisresplenp)) {<br>
++                      Dprint(statp-&gt;options &amp; RES_DEBUG,<br>
++                             (stdout, &quot;;; response may be truncated (UDP)\n&quot;)<br>
++                      );<br>
++              }<br>
++<br>
+               HEADER *anhp = (HEADER *) *thisansp;<br>
+               socklen_t fromlen = sizeof(struct sockaddr_in6);<br>
+               assert (sizeof(from) &lt;= fromlen);<br>
diff --git a/meta/recipes-core/eglibc/<a href="http://eglibc_2.19.bb" rel="noreferrer" target="_blank">eglibc_2.19.bb</a> b/meta/recipes-core/eglibc/<a href="http://eglibc_2.19.bb" rel="noreferrer" target="_blank">eglibc_2.19.bb</a><br>
index a15573c4d19b..66ccedced2d8 100644<br>
--- a/meta/recipes-core/eglibc/<a href="http://eglibc_2.19.bb" rel="noreferrer" target="_blank">eglibc_2.19.bb</a><br>
+++ b/meta/recipes-core/eglibc/<a href="http://eglibc_2.19.bb" rel="noreferrer" target="_blank">eglibc_2.19.bb</a><br>
@@ -29,6 +29,7 @@ SRC_URI = &quot;<a href="http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr25" rel="noreferrer" target="_blank">http://downloads.yoctoproject.org/releases/eglibc/eglibc-${PV}-svnr25</a><br>
            file://CVE-2014-5119.patch \<br>
            file://CVE-2014-7817-wordexp-fails-to-honour-WRDE_NOCMD.patch \<br>
            file://CVE-2012-3406-Stack-overflow-in-vfprintf-BZ-16617.patch \<br>
+           file://CVE-2015-7547.patch \<br>
           &quot;<br>
 SRC_URI[md5sum] = &quot;197836c2ba42fb146e971222647198dd&quot;<br>
 SRC_URI[sha256sum] = &quot;baaa030531fc308f7820c46acdf8e1b2f8e3c1f40bcd28b6e440d1c95d170d4c&quot;<br>
--<br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>