linux-hardening - Re: [PATCH net-next v5 1/8] net: Add 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: <20251104091536.29d543f2@pumpkin>
Date: Tue, 4 Nov 2025 09:15:36 +0000
From: David Laight <david.laight.linux@...il.com>
To: Kees Cook <kees@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
 "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: [PATCH net-next v5 1/8] net: Add struct sockaddr_unsized for
 sockaddr of unknown length

On Mon,  3 Nov 2025 16:26:09 -0800
Kees Cook <kees@...nel.org> wrote:

> Add flexible sockaddr structure to support addresses longer than the
> traditional 14-byte struct sockaddr::sa_data limitation without
> requiring the full 128-byte sa_data of struct sockaddr_storage. This
> allows the network APIs to pass around a pointer to an object that
> isn't lying to the compiler about how big it is, but must be accompanied
> by its actual size as an additional parameter.
> 
> It's possible we may way to migrate to including the size with the
> struct in the future, e.g.:
> 
> struct sockaddr_unsized {
> 	u16 sa_data_len;
> 	u16 sa_family;
> 	u8  sa_data[] __counted_by(sa_data_len);
> };

I'm not sure having that example helps.
At a quick glance it might be thought of as part of the change.
That particular example also has all sorts of issues, so any such
change would have to be very different.

	David

> 
> Signed-off-by: Kees Cook <kees@...nel.org>
> ---
>  include/linux/socket.h | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 3b262487ec06..7b1a01be29da 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -40,6 +40,23 @@ struct sockaddr {
>  	};
>  };
>  
> +/**
> + * struct sockaddr_unsized - Unspecified size sockaddr for callbacks
> + * @sa_family: Address family (AF_UNIX, AF_INET, AF_INET6, etc.)
> + * @sa_data: Flexible array for address data
> + *
> + * This structure is designed for callback interfaces where the
> + * total size is known via the sockaddr_len parameter. Unlike struct
> + * sockaddr which has a fixed 14-byte sa_data limit or struct
> + * sockaddr_storage which has a fixed 128-byte sa_data limit, this
> + * structure can accommodate addresses of any size, but must be used
> + * carefully.
> + */
> +struct sockaddr_unsized {
> +	__kernel_sa_family_t	sa_family;	/* address family, AF_xxx */
> +	char			sa_data[];	/* flexible address data */
> +};
> +
>  struct linger {
>  	int		l_onoff;	/* Linger active		*/
>  	int		l_linger;	/* How long to linger for	*/