[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 04 Apr 2024 11:56:29 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Michal Swiatkowski" <michal.swiatkowski@...ux.intel.com>
Cc: "Alexander Lobakin" <aleksander.lobakin@...el.com>,
"David S . Miller" <davem@...emloft.net>,
"Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
"Paolo Abeni" <pabeni@...hat.com>, "Yury Norov" <yury.norov@...il.com>,
"Alexander Potapenko" <glider@...gle.com>,
nex.sw.ncis.osdt.itp.upstreaming@...el.com,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
"Marcin Szycik" <marcin.szycik@...ux.intel.com>,
"Simon Horman" <horms@...nel.org>, "Kees Cook" <keescook@...omium.org>
Subject: Re: [PATCH net-next v6 19/21] pfcp: always set pfcp metadata
On Thu, Apr 4, 2024, at 11:45, Michal Swiatkowski wrote:
> On Wed, Apr 03, 2024 at 10:59:36PM +0200, Arnd Bergmann wrote:
>> On Wed, Mar 27, 2024, at 16:23, Alexander Lobakin wrote:
>>
>> The memcpy() in the ip_tunnel_info_opts_set() causes
>> a string.h fortification warning, with at least gcc-13:
>>
>> In function 'fortify_memcpy_chk',
>> inlined from 'ip_tunnel_info_opts_set' at include/net/ip_tunnels.h:619:3,
>> inlined from 'pfcp_encap_recv' at drivers/net/pfcp.c:84:2:
>> include/linux/fortify-string.h:553:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>> 553 | __write_overflow_field(p_size_field, size);
>>
>> As far as I can tell, the warning is caused by the
>> ambiguity of the union, but what I noticed is that
>> it also seems to copy a buffer to itself, as 'md'
>> is initialized to tun_dst->u.tun_info as well.
>>
>> Is this intentional?
>
> I used ip_tunnel_info_opts_set() to set options_len and flags.
> You are right that it can and probably should be changed to:
>
> __set_bit(IP_TUNNEL_PFCP_OPT_BIT, tun_dst->u.tun_info.key.tun_flags);
> tun_dst->u.tun_info.options_len = sizeof(*md);
>
> instead of copying the buffer. Thanks for pointing it.
>
> Should I sent a fix to the net or patch to the maintainer? Sorry, don't
> know how this kind of situations are being solved.
I tend to just send fixes when I run into build problems like this,
but since you already know what's going on, I think it's best if
you send the fix as well, citing the warning I mention in the commit
log, and explaining that the warning can be avoided by the simpler
code but is otherwise a false-positive.
Arnd
Powered by blists - more mailing lists