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
| ||
|
Date: Wed, 20 May 2020 11:15:18 +0200 From: "Rafael J. Wysocki" <rafael@...nel.org> To: "Gustavo A. R. Silva" <gustavoars@...nel.org> Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Robert Moore <robert.moore@...el.com>, Erik Kaneda <erik.kaneda@...el.com>, "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, Len Brown <lenb@...nel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" <devel@...ica.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Gustavo A. R. Silva" <gustavo@...eddedor.com>, Kees Cook <keescook@...omium.org> Subject: Re: [PATCH] ACPICA: Replace one-element array and use struct_size() helper On Wed, May 20, 2020 at 12:46 AM Gustavo A. R. Silva <gustavoars@...nel.org> wrote: > > On Tue, May 19, 2020 at 12:25:13PM +0200, Rafael J. Wysocki wrote: > > On Tue, May 19, 2020 at 12:22 AM Gustavo A. R. Silva > > <gustavoars@...nel.org> wrote: > > > > > > The current codebase makes use of one-element arrays in the following > > > form: > > > > > > struct something { > > > int length; > > > u8 data[1]; > > > }; > > > > > > struct something *instance; > > > > > > instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); > > > instance->length = size; > > > memcpy(instance->data, source, size); > > > > > > but the preferred mechanism to declare variable-length types such as > > > these ones is a flexible array member[1][2], introduced in C99: > > > > > > struct foo { > > > int stuff; > > > struct boo array[]; > > > }; > > > > > > By making use of the mechanism above, we will get a compiler warning > > > in case the flexible array does not occur last in the structure, which > > > will help us prevent some kind of undefined behavior bugs from being > > > inadvertently introduced[3] to the codebase from now on. > > > > However, the ACPICA code in the kernel comes from an external project > > and changes of this type are generally not applicable to it unless > > accepted upstream. > > Hi Rafael, > > By _accepted upstream_, in this case, you mean the adoption of the > flexible-arrays in the whole codebase, first? I meant whether or not the patch is accepted by the ACPICA upstream. > If this is the case > notice that there are hundreds of these flexible-array conversions > in mainline, already: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=flexible-array > > Is this what you mean? I'm not actually sure what you mean here.
Powered by blists - more mailing lists