netdev - Re: [musl] Re: [PATCH] uapi: Prevent redefinition of struct iphdr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 25 Dec 2019 20:05:15 -0500
From:   Rich Felker <dalias@...c.org>
To:     David Miller <davem@...emloft.net>
Cc:     AWilcox@...cox-Tech.com, netdev@...r.kernel.org,
        linux-api@...r.kernel.org, musl@...ts.openwall.com
Subject: Re: [musl] Re: [PATCH] uapi: Prevent redefinition of struct iphdr

On Wed, Dec 25, 2019 at 04:34:11PM -0800, David Miller wrote:
> From: "A. Wilcox" <AWilcox@...cox-Tech.com>
> Date: Sun, 22 Dec 2019 00:02:27 -0600
> 
> > @@ -83,6 +83,13 @@
> >  
> >  #define IPV4_BEET_PHMAXLEN 8
> >  
> > +/* Allow libcs to deactivate this - musl has its own copy in <netinet/ip.h> */
> > +
> > +#ifndef __UAPI_DEF_IPHDR
> > +#define __UAPI_DEF_IPHDR	1
> > +#endif
> 
> How is this a musl-only problem?

I don't think it is, unless glibc's includes linux/ip.h to get the
definition, which does not seem to be the case -- at least not on the
Debian system I had handy to check on.

> I see that glibc also defines struct iphdr
> in netinet/ip.h, so why doesn't it also suffer from this?

Maybe it does.

> I find it really strange that this, therefore, only happens for musl
> and we haven't had thousands of reports of this conflict with glibc
> over the years.

It's possible that there's software that's including just one of the
headers conditional on __GLIBC__, and including both otherwise, or
something like that. Arguably this should be considered unsupported
usage; there are plenty of headers where that doesn't work and
shouldn't be expected to.

> I want an explanation, and suitably appropriate adjustments to the commit
> message and comments of this change.

Agreed. Commit messages should not imply that something is a
musl-specific workaround when it's generally the right thing to do.

Rich