netdev - Re: [PATCH net v2] ipv6: sr: fix user space compilation error with old glibc

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: <20170515.100922.2194549018034831667.davem@davemloft.net>
Date:   Mon, 15 May 2017 10:09:22 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     david.lebrun@...ouvain.be
Cc:     netdev@...r.kernel.org, daniel@...earbox.net
Subject: Re: [PATCH net v2] ipv6: sr: fix user space compilation error with
 old glibc

From: David Lebrun <david.lebrun@...ouvain.be>
Date: Mon, 15 May 2017 13:03:20 +0200

> When seg6.h is included in a user space program that also includes
> netinet/in.h, it results in multiple definitions of structures such as
> struct in6_addr. Recent glibc versions have a workaround that consists in
> defining __USE_KERNEL_IPV6_DEFS to prevent duplicates. However, such a
> program will fail to compile with older glibc versions.
> 
> This patch ensures that including seg6.h will work in any case.
> 
> v2: do not try to handle __USE_KERNEL_IPV6_DEFS case in seg6.h
> 
> Fixes: ea3ebc73b46fbdb049dafd47543bb22efaa09c8e ("uapi: fix linux/seg6.h and linux/seg6_iptunnel.h userspace compilation errors")
> Reported-by: Daniel Borkmann <daniel@...earbox.net>
> Signed-off-by: David Lebrun <david.lebrun@...ouvain.be>

Please, no.

The reason we put together a method by which glibc and the kernel can
stay out of eachother's way in header files is exactly so that we
don't need ifdefs that conditionally do netinet/in.h vs. using the
kernel header.

There are more than a dozen other UAPI headers which make use of
linux/in6.h and none of them jump through hoops like what is being
proposed here, and that's on purpose.

So special casing this one one header is really not the way to go.