linux-kernel - Re: ipv6 redefinition build issue with 4.15-rc8

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] [day] [month] [year] [list]

Date:   Sat, 20 Jan 2018 12:11:46 +0100
From:   Hauke Mehrtens <hauke@...ke-m.de>
To:     Jonas Bonn <jonas@...thpole.se>, Daniel Wagner <wagi@...om.org>,
        Neil MacLeod <neil@...cleod.com>
Cc:     connman@...ts.01.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Weimer <fweimer@...hat.com>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8

On 01/18/2018 09:49 AM, Jonas Bonn wrote:
> On 01/17/2018 11:34 PM, Daniel Wagner wrote:
>>
>> On 01/17/2018 11:20 PM, Hauke Mehrtens wrote:
>>>
>>> Do we want to do any changes to the kernel header files? I do not know
>>> of any clean workaround to make this work, we can probably hack
>>> something for connman, but I think it is not worth the trouble.
>>
> 
> Well, it's not _just_ a connman issue, even though it apparently only
> shows up there, currently.
> 
> The problem with the kernel patch is that it now pulls in lib-compat.h
> which causes problems if it appears before netinet/in.h.  The following
> code is sufficient to show the issue:
> 
> #include <linux/libc-compat.h>
> #include <netinet/in.h>
> #include <linux/in6.h>
> 
> int main(int argc, char** argv)
> {
> }
> 
> lib-compat checks if _NETINET_IN_H is defined... it's not.  So it
> defines __UAPI_DEF_IN6_ADDR.
> 
> Then netinet/in.h checks (via bits/in.h) if _LINUX_IN6_H is defined...
> it's not, so it defines the struct in6_addr (and others).
> 
> Then linux/in6.h gets pulled in and redefines the function because the
> earlier libc-compat check told it to do so.
> 
> If you comment out the first #include statement then it compiles fine.
> 
> libc-compat has, as you say, a requirement to be ordered after system
> headers in order for this to work... that doesn't feel terribly robust.
> 
> Anyway, the bug is probably in the glibc headers that are not checking
> the __UAPI_DEF*'s but rather using another broken heuristic... right
> place to fix this is probably there.
> 
> /Jonas

Florian Weimer said here "A lot of combinations are broken, especially
when kernel headers are included first.":
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411192.html

That was on a older version of these two patches:
https://www.mail-archive.com/search?l=linux-kernel@vger.kernel.org&q=subject:%22Re%5C%3A+%5C%5Bmusl%5C%5D+Re%5C%3A+%5C%5BPATCH+resent%5C%5D+uapi+libc+compat%5C%3A+allow+non%5C-glibc+to+opt+out+of+uapi+definitions%22&o=newest&f=1

My understanding is that you should include libc headers before Linux
headers, otherwise you *could* run into problems. There are some
workarounds done to also support including Linux headers first, but they
are not working in all cases.

Hauke