Bug 13651 - resolver fails if result to first query fails but second succeeds
Summary: resolver fails if result to first query fails but second succeeds
Status: RESOLVED DUPLICATE of bug 12994
Alias: None
Product: glibc
Classification: Unclassified
Component: network (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-02 00:27 UTC by Aurelien Jarno
Modified: 2014-06-27 09:58 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-

Attachments
Patch to fix the issue (434 bytes, patch)
2012-02-02 00:27 UTC, Aurelien Jarno 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Aurelien Jarno 2012-02-02 00:27:36 UTC 
Created attachment 6187 [details]
Patch to fix the issue

When using a nameserver which doesn't support IPv6, it might returns FORMERR or NOTIMP, though it's not supposed to be the case according to the RFC. When this corresponds to the first answer (which is usually the case as it's faster to just return an error than doing a recursive query), resplen (that is the returned value) ends up being 0 and resplen2 > 0. The tests in __libc_res_nsearch() only look at resplen and totally ignore resplen2.

The attached patch fixes that by testing if resplen > 0 or resplen == 0 (that is empty result, but no error) and resplen2 > 0.
Comment 1 Ondrej Bilka 2013-10-08 16:40:44 UTC 
Aurelien, did you send this patch to libc-alpha?
Comment 2 Siddhesh Poyarekar 2014-04-16 09:11:34 UTC 

*** This bug has been marked as a duplicate of bug 12994 ***