This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 16 Feb 2016 16:03:41 -0500
- Subject: Re: [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow
- Authentication-results: sourceware.org; auth=none
- References: <56C32C20 dot 1070006 at redhat dot com> <56C32DB0 dot 7090409 at redhat dot com> <20160216181300 dot GC7732 at vapier dot lan> <56C36979 dot 6070403 at redhat dot com> <20160216210031 dot GI7732 at vapier dot lan>
On 02/16/2016 04:00 PM, Mike Frysinger wrote:
> On 16 Feb 2016 13:24, Carlos O'Donell wrote:
>>>> --- a/resolv/res_send.c
>>>> +++ b/resolv/res_send.c
>>>> + Please also note that for TCP we send both queries over the same
>>>> + socket one after another. This technically violates best practice
>>>> + since the server is allowed to read the first query, respond, and
>>>> + then close the socket (to service another client). If the server
>>>> + does this, then the remaining second query in the socket data buffer
>>>> + will cause the server to send the client an RST which will arrive
>>>> + asynchronously and the client's OS will likely tear down the socket
>>>> + receive buffer resulting in a potentially short read and lost
>>>> + response data. This will force the client to retry the query again,
>>>> + and this process may repeat until all servers and connection resets
>>>> + are exhausted and then the query will fail. It's not known if this
>>>> + happens with any frequency in real DNS server implementations. This
>>>> + implementation should be corrected to use two sockets by default for
>>>> + parallel queries.
>>> should we open a bug now for this ?
>> Yes. Would you mind helping with that?