[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533036d7-1a0e-21e8-5e40-2e807b32a215@embeddedor.com>
Date: Mon, 9 Aug 2021 16:32:27 -0500
From: "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To: Brian Norris <briannorris@...omium.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>
Cc: Amitkumar Karwar <amitkarwar@...il.com>,
Ganapathi Bhat <ganapathi017@...il.com>,
Sharvari Harisangam <sharvari.harisangam@....com>,
Xinming Hu <huxinming820@...il.com>,
Kalle Valo <kvalo@...eaurora.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
linux-wireless <linux-wireless@...r.kernel.org>,
netdev@...r.kernel.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH][next] mwifiex: usb: Replace one-element array with
flexible-array member
On 8/9/21 16:24, Brian Norris wrote:
> On Mon, Aug 9, 2021 at 2:08 PM Gustavo A. R. Silva
> <gustavoars@...nel.org> wrote:
>>
>> There is a regular need in the kernel to provide a way to declare having
>> a dynamically sized set of trailing elements in a structure. Kernel code
>> should always use “flexible array members”[1] for these cases. The older
>> style of one-element or zero-length arrays should no longer be used[2].
>>
>> This helps with the ongoing efforts to globally enable -Warray-bounds
>> and get us closer to being able to tighten the FORTIFY_SOURCE routines
>> on memcpy().
>>
>> This issue was found with the help of Coccinelle and audited and fixed,
>> manually.
>>
>> [1] https://en.wikipedia.org/wiki/Flexible_array_member
>> [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays
>>
>> Link: https://github.com/KSPP/linux/issues/79
>> Link: https://github.com/KSPP/linux/issues/109
>> Signed-off-by: Gustavo A. R. Silva <gustavoars@...nel.org>
>
> An important part of your patch rationale should include determining
> that the 1-length wasn't actually important anywhere. I double checked
> for you, and nobody seemed to be relying on 'sizeof struct fw_data' at
> all, so this should be OK:
I always do that. That's the reason why I included this line in the
changelog text:
"This issue was found with the help of Coccinelle and audited and fixed,
manually."
Thanks for double-checking, though. :)
> Reviewed-by: Brian Norris <briannorris@...omium.org>
Thanks
--
Gustavo
Powered by blists - more mailing lists