musl - Behavior change in getaddrbyname() with AF

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <DM6PR21MB16119FB8E9D5AE1E364D42ABB6C39@DM6PR21MB1611.namprd21.prod.outlook.com>
Date: Sat, 14 Jan 2023 22:56:28 +0000
From: Barry Bond <barrybo@...rosoft.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Behavior change in getaddrbyname() with AF_UNSPEC

This is related to this change:  https://git.musl-libc.org/cgit/musl/commit/?id=5cf1ac2443ad0dba263559a3fe043d929e0e5c4c made back in 2020.

In the repro case, getaddrbyname() with AF_UNSPEC sends out two requests, but only gets back a single response, with the ipv4 address.   There is no ipv6 on the network.

name_from_dns() contains the relevant code.  After __res_msend_rc() returns, 'nq' is 2, and 'alens' is [96, 0], indicating that there was an ipv4 response of 96 bytes, but no response for ipv6.  Then the validation code runs:

                for (i=0; i<nq; i++) {
                                if (alens[i] < 4 || (abuf[i][3] & 15) == 2) return EAI_AGAIN;
                                if ((abuf[i][3] & 15) == 3) return 0;
                                if ((abuf[i][3] & 15) != 0) return EAI_FAIL;
                }

and the result is EAI_AGAIN, because alens[1]==0.

Before this patch, the code would have parsed the ipv4 response via __dns_parse(), failed to parse the empty second response because alens[1]<12, and the function would return with ctx.cnt==1.

I propose adding one new check at the top of the for() loop:
                if (alens[i] == 0) continue; /* response timed out */

Thanks!
Barry - Microsoft Azure Sphere

Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.