From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3997 invoked from network); 12 Apr 2022 16:40:07 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Apr 2022 16:40:07 -0000 Received: (qmail 22082 invoked by uid 550); 12 Apr 2022 16:40:03 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22047 invoked from network); 12 Apr 2022 16:40:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1649781591; bh=Yk0k3ElnYnwZwHOnqZnn4JcGIxexavVvwy1pgsTWfZ8=; h=X-UI-Sender-Class:Date:From:To:Subject; b=d+CDzGNaNxEpBsIHEzz5MiZ2DyVl5Cy+4glr+nyGRrq/c2peH8uCpfY+Sud6DLWC7 vAKXOZ92Qvkbxsa9FmgbjWBXTigiT+MDhy51U2zYYJS08FUNyxi/QxQEJawXwVptno 3kmGHDTzXRHex9ysQLF5yKiWgpWXDpMhClHHeEDg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Tue, 12 Apr 2022 18:39:50 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220412163950.GD8499@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:mjSRuhDr04jQ+uXgix7D+M4n9Q+nbkVLM3IVqfxd7/3SO7jxmh5 CRz6CYAXmPXik9Dd553c3iCzhnzr2CMO30VNyBLyRvlSAjVXXKuZC+PwToG+V7NYJ3G41l/ sFmxExBEGhLLEyutfstaW7cNg9QxGh2aQYAs/W8V2hAB0WolahLOMybJM5scfFdwo/h43Ub /9Ibv0ZaKMOTSTujvRrhw== X-UI-Out-Filterresults: notjunk:1;V03:K0:1Po3slNztm0=:Sse5uqlVxCUiM0+leIYoGZ rcpLd2uqOLoUglbOQcO9bP3uJ2x0/Oawzi0PocPLxO/ukObYdyS7iOP3U6mbQjmJoVdHvMcgt hkX8aYUupAbBljJfaOXLp3boranNR6WmSFLUrtzNYgtdtzb1Jm8R7NJe3FNqOA2Q4krRhMFFq Y1PBQfVM9TM0KXzGIGabnKEKsNhFjS31GMENTUAe4gDQA5fG3WDvfSoMUN9t6RNU675bhVutx d8hjen6ZWyll9dhAY5R9wwa4OJ45HqjDMw/3xk06K/ADLj82epYNcwxeHh/YheK+9c1UKZzwD N55PAHPpCjaCQxXjx2hmz2yiQVjpp8UV+T+M3FiTzRRs6KT+zPwB2s7Djn0JFgOy/KOpGuYMd lPxVkTlbOTNbu9TX32bUilHJ/GmHC+d55dGq4e1/NMjble/W/x+1HfzQXIz1ankXKc/Xqp5Wf UZH07FulfTFgwHPvB12oRmY7lDzZap0ka7sAmfPImpOM0dO+rQQlZhvxkLxRU1pTCl72X9Uav afq0yOCLZcJJ0siPhshP+l5JC9yJmX/qIm3PONwdALSyBJalegLb0YSUXYxSf3zHEptgCCbjW TndiOqooE341jkx9RZXIyOZUOoAM1+SROM9YcIQqU4Y21lRnjQwGdmfOwpAd8EDITaOSPiYIj kwtzpQjuI/V9qTxchXO2wlcwj4orn6GHcsnqHmDZjCdySPl/985yyrmZhSlEl6/aXRU81FHSj DUoSj12zRvzvVg4NKs+NddzmLr8cPqZ4s5YpmcSVmrfbMQMLR+yALWTrCl/ytjNYaMrBFZ6Sh Tk5ggf/qSVg58m7PE7TuHotHQebwBKzxv15jxBqvDAI+NQ8+U7PullQsHBI6ceg7TnSKV6iLY yDihz+Q5Z3awcuSGF8O5FUyRhpUfh60PhY8FCXl+AIKWnjKRojAZ73nkHhuvn9B8Acod63ZIi qEs605tPtGeDzE/QWexyufWNox0o4A6STNEURX3+HVmmZadXgBMiNInGBGFweIq6g4ZE6jQMF oHAi3UCyrqMTK11QBCxtJ2c8MaZWhlahDPU+qGdFPS3zC3Oy7frDYPA7ohuZDvobkSE/14DJg Mg9X4dxjrps3YI= Subject: [musl] res_msend_rc problem with IPv6? Hi all, I don't know if this is intentional, but while reading the code for the DNS resolver (I was trying to figure out if the musl resolver uses a randomized source port. It doesn't), I noticed a problem in the code. __res_msend_rc() contains these lines at the start: |/* Get local address and open/bind a socket */ |sa.sin.sin_family = family; |fd = socket(family, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0); | |/* Handle case where system lacks IPv6 support */ |if (fd < 0 && family == AF_INET6 && errno == EAFNOSUPPORT) { | fd = socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0); | family = AF_INET; |} |if (fd < 0 || bind(fd, (void *)&sa, sl) < 0) { | if (fd >= 0) close(fd); | pthread_setcancelstate(cs, 0); | return -1; |} If "family" is AF_INET6, and the kernel returns EAFNOSUPPORT, the bind() call will always fail. This is because in that case, "fd" will refer to an IPv4 socket, but both "sa" and "sl" will reflect an IPv6 address. Binding an IPv4 socket to an IPv6 address does not work. I tested it! It is, of course, entirely possible that you do not want res_msend() to succeed if resolv.conf contains an IPv6 address, but the kernel does not support IPv6. In that case, might I suggest making this explicit in the if-statement? In the event this was not intentional, a possible solution would be to set "sl" back to the length of an IPv4 address inside of the if-statement and moving the assignment to "sa.sin.sin_family" behind the if-statement. Then later on in the send loop, you could just skip the sendto() for all addresses with the wrong address family, since in the case where we are sending to IPv6, all IPv4 addresses have been converted already, so the only possible mismatches would be IPv6 addresses when sending to IPv4. Or you could just not bother and let these sendto() calls fail silently. In either case, these numbers cannot possibly come up as addresses received from, and so cannot be resent to, either. Ciao, Markus