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

Message-ID: <bff0e61d-ed89-d907-66b5-0bc30a1e36fe@southpole.se>
Date:   Thu, 18 Jan 2018 09:49:56 +0100
From:   Jonas Bonn <jonas@...thpole.se>
To:     Daniel Wagner <wagi@...om.org>, Hauke Mehrtens <hauke@...ke-m.de>,
        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>
Subject: Re: ipv6 redefinition build issue with 4.15-rc8

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