From: Simon Horman <horms@kernel.org>
To: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH net-next] selftests/net/ipsec: Fix variable size type not at the end of struct
Date: Thu, 27 Nov 2025 18:25:30 +0000 [thread overview]
Message-ID: <aSiXmp4mh7M3RaRv@horms.kernel.org> (raw)
In-Reply-To: <20251126054711.26465-1-ankitkhushwaha.linux@gmail.com>
On Wed, Nov 26, 2025 at 11:17:11AM +0530, Ankit Khushwaha wrote:
> The "struct alg" object contains a union of 3 xfrm structures:
>
> union {
> struct xfrm_algo;
> struct xfrm_algo_aead;
> struct xfrm_algo_auth;
> }
>
> All of them end with a flexible array member used to store key material,
> but the flexible array appears at *different offsets* in each struct.
> bcz of this, union itself is of variable-sized & Placing it above
> char buf[...] triggers:
>
> ipsec.c:835:5: warning: field 'u' with variable sized type 'union
> (unnamed union at ipsec.c:831:3)' not at the end of a struct or class
> is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> 835 | } u;
> | ^
FWIIW, I was able to reproduce this using the
-Wflex-array-member-not-at-end (n.b. different option name to above)
option with the GCC 15.2.0 toolchain here [1].
[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/
>
> one fix is to use "TRAILING_OVERLAP()" which works with one flexible
> array member only.
>
> But In "struct alg" flexible array member exists in all union members,
> but not at the same offset, so TRAILING_OVERLAP cannot be applied.
>
> so the fix is to explicitly overlay the key buffer at the correct offset
> for the largest union member (xfrm_algo_auth). This ensures that the
> flexible-array region and the fixed buffer line up.
>
> No functional change.
I verified this does not change the layout of the union (now structure),
by copying it outside the function and giving it a name.
And then analysing the binary using pahole.
So I agree this should not have any run-time effect.
But I've CCed Gustavo and linux-hardening, as their experience
seems relevant here.
>
> Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> tools/testing/selftests/net/ipsec.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/net/ipsec.c b/tools/testing/selftests/net/ipsec.c
> index 0ccf484b1d9d..f4afef51b930 100644
> --- a/tools/testing/selftests/net/ipsec.c
> +++ b/tools/testing/selftests/net/ipsec.c
> @@ -43,6 +43,10 @@
>
> #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>
> +#ifndef offsetof
> +#define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER)
> +#endif
> +
> #define IPV4_STR_SZ 16 /* xxx.xxx.xxx.xxx is longest + \0 */
> #define MAX_PAYLOAD 2048
> #define XFRM_ALGO_KEY_BUF_SIZE 512
> @@ -827,13 +831,16 @@ static int xfrm_fill_key(char *name, char *buf,
> static int xfrm_state_pack_algo(struct nlmsghdr *nh, size_t req_sz,
> struct xfrm_desc *desc)
> {
> - struct {
> + union {
> union {
> struct xfrm_algo alg;
> struct xfrm_algo_aead aead;
> struct xfrm_algo_auth auth;
> } u;
> - char buf[XFRM_ALGO_KEY_BUF_SIZE];
> + struct {
> + unsigned char __offset_to_FAM[offsetof(struct xfrm_algo_auth, alg_key)];
> + char buf[XFRM_ALGO_KEY_BUF_SIZE];
> + };
> } alg = {};
> size_t alen, elen, clen, aelen;
> unsigned short type;
prev parent reply other threads:[~2025-11-27 18:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-26 5:47 [PATCH net-next] selftests/net/ipsec: Fix variable size type not at the end of struct Ankit Khushwaha
2025-11-27 18:25 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aSiXmp4mh7M3RaRv@horms.kernel.org \
--to=horms@kernel.org \
--cc=ankitkhushwaha.linux@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.