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=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32608 invoked from network); 24 Aug 2022 19:04:08 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2022 19:04:08 -0000 Received: (qmail 11794 invoked by uid 550); 24 Aug 2022 19:04:05 -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 11711 invoked from network); 24 Aug 2022 19:04:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1661367829; bh=He2dDOZ+BGdn/4zEo+shAIipZx5bisQnf1iruQGevt0=; h=X-UI-Sender-Class:Date:From:To:Subject; b=DRf6/d09ASShPuafCj47zeYOkOUE6LfQejQBOsGrA7DFu//DCkNE6wkreQwdu7qXQ aeWopkI9y3PdOsFWz+SFIwm1WnJdJOuy/bDqQSlwooM4ZSjXhxUKdI/418oielirFE isfcK+SsUbrVRQt3YWPSgxAZxFzyerW43GJ0Ejtw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Wed, 24 Aug 2022 21:03:49 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220824190349.GB1923@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:YzepskXqmmovDLYa9eexg9OCsP+ogHW8qLVYnxqhx/9ur1tC+Pc PQ9syMc4094RqYnySiRi/cn3pwWBOEXdAzH1dHrxy4tuYPRRv9rYHeiB219IEDE0DcE1AGU r3wWEGygQX4yBBZey6zvdAhDsE/0AFxB38+OVNqKU6Ctso3P6cL6nOweKFLN8OmGnk2z6/R U3HkmSSeEBhRGqZK6Lgtw== X-UI-Out-Filterresults: notjunk:1;V03:K0:weBvppZwYfQ=:cpTx1eZaPnYEqgifhCzxsz G6Bk+/OZyKpX224/yWoyMzmZpwDsPfsjZKEiaYIBC8f047u5bsLtddG20UZp7ZJUpeBtlmnAZ Xv8u4VEJk31XJSebY0QupUCHAeH4SBm3YggfrSK0/y6hH4l1ZC8BtCE+esF9xNePE989a/Z1p KTd3sMZo3mNu6RbH5CK1gycpTW3SMrPhXrjjznaBiYkji0sdx9hI10JpBsCaZFnVA3J5r8chX Ro2qzlVm0LLQ+JXanc1ZenqOJTYHSkEG8W49EawshuO8Q0lWlRTNJv5G+ep/R2+wO2YcnYsyl eyiRBU88jK9PGqGGEigNdAhoPnOAFdqMiumFwHvNfWBSQO7kgETwlsk8bCOvQmx4h6UgsvB2G 7/DWp9hcrMtVpAWrGmWdBmofPzMl3hgE4hhvPA5U6dZzZitsNDE7omfUN2RLpkxfzu23zCIZ7 7gbwp64oUiCYgxeGedT6yUtZuTgbq/w5z1TonNh612AWW4TQKmCME29NL3OMPUbVNarC8GOl9 vvkNvssxdRsQXYulYD+zHoU6L+f8LT1MdWp+HvsiOi2g2/yzf831m0rHu6YnnqtsQAsrGJ9Kr KTK/cf9ih9yUn63QnYBEn67Vhp1L/6uuzU5SloXPL7D+5SQGBRhGlmZbtWal1RMruTF0Wg+a6 UbhsOCjf1EraSLFz9W76cNQhSdyPriw8mR9Kom9q8zmgpQgzwiaPl2179pVY2cAO3SuZsJE93 Xoust/1ZC4mn+JG/aFaI7PzFDkjKYiTE0vvckx7EGs4kyW2p53Z+Xl9yS6Q78/1gI0Wlq6KYz 7sdlRhEl3WnKIjn0oENglhO53oHWviHanSg8QVM+8tc/+NU5FFIjA53iBzXwBwVeBhJkkvp9d mOzOOComOckNeW9EDjNhIX06IEPw3P8lD56fyFlCSzSaF2nliKi3IEq/1DDo6xj26aoLw1M9n eEKfvAKWBvnHDzOEZ9y4Ctjn/5NvAwG4aZKhJk0XZy3epl5EdGdr/d6H6GYrnlhycObfhFpmH 9wWF+KxDr3FRIxGynINTCtaJWfxje19RjMC/9cuEK1hXguNtbsQbVIXsg6XFW518kFLNhOQgC lLJ9VDOkdXCHV6mCQpvkarVUFQpI8Wq7WFRnCZ23mOAkoqibSchpFv9AA== Subject: [musl] IPv4 fallback in __res_msend_rc not functional Hi all, I noticed something while reading some code: There is a fallback in __res_msend_rc(), in case an IPv6 socket is requested but cannot be allocated. In that case, the function tries to create an IPv4 socket instead. However, I do not think this code can work that way. For reference, this is the code: /* 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; } The problem is, if the fallback is triggered, the local address is still set to be an IPv6 address, and so the bind() must necessarily fail with EINVAL. The fix depends on whether the fallback is still intended functionality or not. If not, then the easiest would be to just get rid of the entire fallback block. If the fallback is still intended to work, then the fallback block must reset sl to the length of an IPv4 socket, and the setting of sa.sin.sin_family must be delayed until after that block. There is also the issue of the sendto() loop further down in the function. If it is intended that the socket can be an IPv4 socket but there can be IPv6 addresses in the list, then it might be prudent to prevent sendto() from sending to the wrong address family. Or not, I mean, you do not test for errors from sendto(), and the sends to the wrong address family are just going to fail. So they would only waste time and change errno, but not much of a visible side effect. Ciao, Markus