linux-hardening - Re: [net-next PATCH v4 0/7] net: Introduce 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: <20251031170719.65fb8163@kernel.org>
Date: Fri, 31 Oct 2025 17:07:19 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, "Gustavo A. R. Silva"
 <gustavo@...eddedor.com>, Alexei Starovoitov <ast@...nel.org>, Daniel
 Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Simon Horman <horms@...nel.org>, Kuniyuki Iwashima
 <kuniyu@...gle.com>, Willem de Bruijn <willemb@...gle.com>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
 linux-hardening@...r.kernel.org
Subject: Re: [net-next PATCH v4 0/7] net: Introduce struct sockaddr_unsized

On Wed, 29 Oct 2025 14:43:57 -0700 Kees Cook wrote:
> The historically fixed-size struct sockaddr is part of UAPI and embedded
> in many existing structures. The kernel uses struct sockaddr extensively
> within the kernel to represent arbitrarily sized sockaddr structures,
> which caused problems with the compiler's ability to determine object
> sizes correctly. The "temporary" solution was to make sockaddr explicitly
> use a flexible array, but this causes problems for embedding struct
> sockaddr in structures, where once again the compiler has to guess about
> the size of such objects, and causes thousands of warnings under the
> coming -Wflex-array-member-not-at-end warning.
> 
> Switching to sockaddr_storage internally everywhere wastes a lot of memory,
> so we are left with needing two changes:
> - introduction of an explicitly arbitrarily sized sockaddr struct
> - switch struct sockaddr back to being fixed size
> 
> Doing the latter step requires all "arbitrarily sized" uses of struct
> sockaddr to be replaced with the new struct from the first step.
> 
> So, introduce the new struct and do enough conversions that we can
> switch sockaddr back to a fixed-size sa_data.

This doesn't apply to net-next.. Now I kinda wondering if maybe you
skipped a patch? The code itself LGTM.