netdev - Re: [PATCH net-next] net: uapi: Provide an UAPI definition of 'struct sockaddr'

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: <20260112124604-dbf7f68d-2182-438f-9495-2931cac02a81@linutronix.de>
Date: Mon, 12 Jan 2026 12:55:07 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Florian Weimer <fweimer@...hat.com>, Arnd Bergmann <arnd@...db.de>
Cc: Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Willem de Bruijn <willemb@...gle.com>, Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org, 
	linux-api@...r.kernel.org
Subject: Re: [PATCH net-next] net: uapi: Provide an UAPI definition of
 'struct sockaddr'

On Mon, Jan 12, 2026 at 12:42:17PM +0100, Florian Weimer wrote:
> * Arnd Bergmann:
> 
> > On Wed, Jan 7, 2026, at 00:13, Jakub Kicinski wrote:
> >> On Tue, 6 Jan 2026 11:32:52 +0100 Thomas Weißschuh wrote:
> >>> As for the failure in netdev CI however I am not so sure.
> >>> Looking at net-next-2026-01-05--12-00, the only failures triggered by my
> >>> change are also the ones from the bpf-ci. Are these the ones you meant,
> >>> or am I missing some others?
> >>
> >> Multiple things broke at once so slightly hard to fish the relevant
> >> stuff out from here:
> >>
> >> https://netdev.bots.linux.dev/contest.html?branch=net-next-2026-01-05--15-00&pass=0&pw-n=0
> >>
> >> Here's one:
> >>
> >> make[1]: Entering directory 
> >> '/home/virtme/testing/wt-3/tools/testing/selftests/net'
> >>   CC       busy_poller
> >> In file included from [01m[K/usr/include/sys/socket.h:33[m[K,
> >>                  from [01m[K/usr/include/netinet/in.h:23[m[K,
> >>                  from [01m[K/usr/include/arpa/inet.h:22[m[K,
> >>                  from [01m[Kbusy_poller.c:14[m[K:
> >> [01m[K/usr/include/bits/socket.h:182:8:[m[K [01;31m[Kerror: 
> >> [m[Kredefinition of '[01m[Kstruct sockaddr[m[K'
> >
> >>                  from [01m[Kbusy_poller.c:12[m[K:
> >> [01m[K/home/virtme/testing/wt-3/usr/include/linux/socket.h:37:8:[m[K 
> >> [01;36m[Knote: [m[Koriginally defined here
> >
> > Maybe we can change all the instances of 'struct sockaddr' in
> > include/uapi/ to reference a new 'struct __kernel_sockaddr',
> > and then redirect that one if the libc header got included
> > first?
> >
> > struct __kernel_sockaddr {
> >        __kernel_sa_family_t    sa_family;      /* address family, AF_xxx       */
> >        char sa_data_min[14];           /* Minimum 14 bytes of protocol address */
> > };
> > #ifdef _SYS_SOCKET_H
> > #define __kernel_sockaddr sockaddr
> > #endif

I'm not a big fan of such a define in a generic header.

I do have a v2 of this patch currently in 0day. It reorders the inclusions
in the affected selftests. While it feels like a hack, interspersing the
different types of headers may already break randomly due to issues in
libc-compat.h (see below)

> > This will still fail when a user application includes linux/if.h
> > before sys/socket.h and then expects the structures in linux/if.h
> > to contain the libc version of sockaddr, but hopefully that is
> > much rarer. A survey of codesearch.debian.net shows almost all
> > users of linux/if.h first including sys/socket.h, and most of
> > them not caring about struct sockaddr either.

The whole linux/libc-compat.h machinery is brittle when UAPI headers are
included before libc headers. It will only detect the included libc headers
on its first inclusion. If overlapping libc and UAPI after that, they will
run into symbol clashes.

> If you call the data member sa_data just like glibc, it will only fail
> in C++, not C.  GCC considers the two definitions sufficiently
> equivalent (even though glibc adds a may_alias attribute to meet POSIX
> requirements), and duplicate definitions are permitted in C.

clang is not so lenient and will error out.

> C++ with modules will probably support duplicate definitions, too, but I
> haven't checked if it's possible to get this work with GCC 16.


Thomas