linux-kernel - RE: [PATCH 1/5][next] net: dev: 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: <9e6a2efa17b94522ad2274332f608c38@AcuMS.aculab.com>
Date: Tue, 22 Oct 2024 12:13:56 +0000
From: David Laight <David.Laight@...LAB.COM>
To: "'Gustavo A. R. Silva'" <gustavoars@...nel.org>, Andrew Lunn
	<andrew+netdev@...n.ch>, Johannes Berg <johannes@...solutions.net>, "David
 Ahern" <dsahern@...nel.org>, "David S. Miller" <davem@...emloft.net>, "Eric
 Dumazet" <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>, Kees Cook
	<kees@...nel.org>
Subject: RE: [PATCH 1/5][next] net: dev: Introduce struct sockaddr_legacy

From: Gustavo A. R. Silva
> Sent: 16 October 2024 01:27
> 
> We are currently working on enabling the -Wflex-array-member-not-at-end
> compiler option. This option has helped us detect several objects of
> the type `struct sockaddr` that appear in the middle of composite
> structures like `struct rtentry`, `struct compat_rtentry`, and others:
> 
...
> 
> In order to fix the warnings above, we introduce `struct sockaddr_legacy`.
> The intention is to use it to replace the type of several struct members
> in the middle of composite structures, currently of type `struct sockaddr`.
> 
> These middle struct members are currently causing thousands of warnings
> because `struct sockaddr` contains a flexible-array member, introduced
> by commit b5f0de6df6dce ("net: dev: Convert sa_data to flexible array in
> struct sockaddr").
> 
> The new `struct sockaddr_legacy` doesn't include a flexible-array
> member, making it suitable for use as the type of middle members
> in composite structs that don't really require the flexible-array
> member in `struct sockaddr`, thus avoiding -Wflex-array-member-not-at-end
> warnings.
> 
> Signed-off-by: Gustavo A. R. Silva <gustavoars@...nel.org>
> ---
>  include/linux/socket.h | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index d18cc47e89bd..f370ae0e6c82 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -40,6 +40,25 @@ struct sockaddr {
>  	};
>  };
> 
> +/*
> + * This is the legacy form of `struct sockaddr`. The original `struct sockaddr`
> + * was modified in commit b5f0de6df6dce ("net: dev: Convert sa_data to flexible
> + * array in struct sockaddR") due to the fact that "One of the worst offenders
> + * of "fake flexible arrays" is struct sockaddr". This means that the original
> + * `char sa_data[14]` behaved as a flexible array at runtime, so a proper
> + * flexible-array member was introduced.
> + *
> + * This caused several flexible-array-in-the-middle issues:
> + * https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end

I'd bet that the code even indexed the array?
So it is all worse that just a compiler warning/

> + *
> + * `struct sockaddr_legacy` replaces `struct sockaddr` in all instances where
> + * objects of this type do not appear at the end of composite structures.
> + */
> +struct sockaddr_legacy {
> +	sa_family_t	sa_family;	/* address family, AF_xxx	*/
> +	char 		sa_data[14];	/* 14 bytes of protocol address	*/
> +};
> +

I'm not sure that is a very good name.
Reading it you don't know when it is 'legacy' from.
It's size is clearly that of the original IPv4 sockaddr.
(I'm not sure there was ever an earlier one.)

Perhaps 'strict sockaddr_16' would be better?
Or, looking at the actual failures, sockaddr_ipv4?

Alternatively revert b5f0de6df6dce and add a new type that has the char[]
field??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)