[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202306071417.79F70AC@keescook>
Date: Wed, 7 Jun 2023 14:19:51 -0700
From: Kees Cook <keescook@...omium.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Eric Biederman <ebiederm@...ssion.com>,
Mark Brown <broonie@...nel.org>,
Dave Martin <Dave.Martin@....com>,
Catalin Marinas <catalin.marinas@....com>,
linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] binfmt_elf: dynamically allocate note.data in
parse_elf_properties
On Wed, Jun 07, 2023 at 04:42:27PM +0200, Christian Marangi wrote:
> Dynamically allocate note.data in parse_elf_properties to fix
> compilation warning on some arch.
I'd rather avoid dynamic allocation as much as possible in the exec
path, but we can balance it against how much it may happen.
> On some arch note.data exceed the stack limit for a single function and
> this cause the following compilation warning:
> fs/binfmt_elf.c: In function 'parse_elf_properties.isra':
> fs/binfmt_elf.c:821:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> 821 | }
> | ^
> cc1: all warnings being treated as errors
Which architectures see this warning?
> Fix this by dynamically allocating the array.
> Update the sizeof of the union to the biggest element allocated.
How common are these notes? I assume they're very common; I see them
even in /bin/true:
$ readelf -lW /bin/true | grep PROP
GNU_PROPERTY 0x000338 0x0000000000000338 0x0000000000000338 0x000030 0x000030 R 0x8
--
Kees Cook
Powered by blists - more mailing lists