linux-kernel - Re: [RFC] xfrm: convert alg_key to flexible array member

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] [day] [month] [year] [list]

Message-ID: <20220623104948.GD566407@gauss3.secunet.de>
Date:   Thu, 23 Jun 2022 12:49:48 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     <netdev@...r.kernel.org>, Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] xfrm: convert alg_key to flexible array member

On Thu, Jun 02, 2022 at 12:45:15PM +0200, Steffen Klassert wrote:
> On Tue, May 24, 2022 at 01:47:40PM -0700, Stephen Hemminger wrote:
> > Iproute2 build generates a warning when built with gcc-12.
> > This is because the alg_key in xfrm.h API has zero size
> > array element instead of flexible array.
> > 
> >     CC       xfrm_state.o
> > In function ‘xfrm_algo_parse’,
> >     inlined from ‘xfrm_state_modify.constprop’ at xfrm_state.c:573:5:
> > xfrm_state.c:162:32: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
> >   162 |                         buf[j] = val;
> >       |                         ~~~~~~~^~~~~
> > 
> > This patch convert the alg_key into flexible array member.
> > There are other zero size arrays here that should be converted as
> > well.
> > 
> > This patch is RFC only since it is only compile tested and
> > passes trivial iproute2 tests.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>
> 
> I've put this today to our test systems and it showed no problems,
> so we can integrate it after the merge window.

This is now applied to ipsec-next, thanks!