[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220206213032.GU7074@brightrain.aerifal.cx>
Date: Sun, 6 Feb 2022 16:30:33 -0500
From: Rich Felker <dalias@...ifal.cx>
To: Satadru Pramanik <satadru@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: musl getaddr info breakage on older kernels
On Sun, Feb 06, 2022 at 03:32:40PM -0500, Satadru Pramanik wrote:
> Hello,
>
> I'm a dev for the Chromebrew linux distribution, and we've been trying to
> support older EOL i686 chromebooks stuck on older kernels.
>
> We have noticed that running newer versions of musl on such machines breaks
> getaddrinfo in musl. This is a problem as we are trying to build
> musl-static builds of curl and git which will work on these older machines.
> (This is really irritating since these binaries work fine in i686
> containers on newer machines running newer kernels, but then fail when run
> on the hardware which has the older kernels.)
The problem is almost surely not the kernel or musl but either buggy
nameservers or buggy Docker. Can you post the strace log of the
failing test case? That would quickly determine which it is.
> I have been attempting to bisect where this happens, and have
> determined that the first commit which breaks DNS resolution on musl for
> these older machines is
> https://git.musl-libc.org/cgit/musl/commit/?id=2f2348c9588d61680123bbe438db38acf5dfea4c
This commit does not change anything in musl, which does not use those
macros at all internally, just the public headers. So the bisect
result must be wrong.
> (I emailed you since you are the person who made that commit.)
Please mail the list. I've CC'd it in my reply here.
> Just applying a reverse of that commit allows musl networking to work
> properly up to the (2020-03-14) 2b2c8aafce9d80f9d58652643538f4d58e82b856
> commit. I'm trying newer commits with a
> 2f2348c9588d61680123bbe438db38acf5dfea4c reversal patch to see if where
> networking breaks again, as later commits such as the (2020-05-18)
> fd7ec068efd590c0393a612599a4fab9bb0a8633 commit have broken ipv6 DNS
> resolving.
>
> I'd like to be able to get this issue fixed, as we would like to use a
> newer version of musl not susceptible to CVE-2020-28928.
>
> The test case I'm using is the code at
> https://www.openwall.com/lists/musl/2021/07/19/1
>
> Our implementation is here:
> https://github.com/skycocker/chromebrew/blob/master/packages/musl_getaddrinfo_test.rb
>
> Once I find other commits which are breaking this, I'd like to be able to
> get a patch integrated into musl so that we don't have to maintain a
> patchset for older machines.
>
> Would that be feasible? And my apologies if this should have gone to one of
> the mailing lists first. I figured I should ask you since you might have
> the most insight into this breaking installs.
>
> Here is the current reversal patch we are testing with:
>
> --- b/include/arpa/inet.h
> +++ a/include/arpa/inet.h
> @@ -24,6 +24,11 @@
> in_addr_t inet_lnaof(struct in_addr);
> in_addr_t inet_netof(struct in_addr);
>
> +#undef INET_ADDRSTRLEN
> +#undef INET6_ADDRSTRLEN
> +#define INET_ADDRSTRLEN 16
> +#define INET6_ADDRSTRLEN 46
> +
> #ifdef __cplusplus
> }
> #endif
> --- b/include/netinet/in.h
> +++ a/include/netinet/in.h
> @@ -60,6 +60,8 @@
>
> extern const struct in6_addr in6addr_any, in6addr_loopback;
>
> +#undef INET_ADDRSTRLEN
> +#undef INET6_ADDRSTRLEN
> #define INET_ADDRSTRLEN 16
> #define INET6_ADDRSTRLEN 46
>
> Thanks,
>
> Satadru Pramanik
> Dev Team
> Chromebrew
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
