netdev - Re: [PATCH v2 net-next] ipv6: remove hard coded limitation on ipv6

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZLqJ8bUGfYrTp/9P@corigine.com>
Date: Fri, 21 Jul 2023 14:36:49 +0100
From: Simon Horman <simon.horman@...igine.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, eric.dumazet@...il.com,
	Chao Wu <wwchao@...gle.com>, Wei Wang <weiwan@...gle.com>,
	Coco Li <lixiaoyan@...gle.com>, YiFei Zhu <zhuyifei@...gle.com>
Subject: Re: [PATCH v2 net-next] ipv6: remove hard coded limitation on
 ipv6_pinfo

On Thu, Jul 20, 2023 at 11:09:01AM +0000, Eric Dumazet wrote:
> IPv6 inet sockets are supposed to have a "struct ipv6_pinfo"
> field at the end of their definition, so that inet6_sk_generic()
> can derive from socket size the offset of the "struct ipv6_pinfo".
> 
> This is very fragile, and prevents adding bigger alignment
> in sockets, because inet6_sk_generic() does not work
> if the compiler adds padding after the ipv6_pinfo component.
> 
> We are currently working on a patch series to reorganize
> TCP structures for better data locality and found issues
> similar to the one fixed in commit f5d547676ca0
> ("tcp: fix tcp_inet6_sk() for 32bit kernels")
> 
> Alternative would be to force an alignment on "struct ipv6_pinfo",
> greater or equal to __alignof__(any ipv6 sock) to ensure there is
> no padding. This does not look great.
> 
> v2: fix typo in mptcp_proto_v6_init() (Paolo)
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

...

Reviewed-by: Simon Horman <simon.horman@...igine.com>