linux-kernel - Re: [PATCH] ELF: fix overflow in total mapping size calculation

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]

Date:   Thu, 7 Oct 2021 21:31:40 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ELF: fix overflow in total mapping size calculation

On Thu, Oct 07, 2021 at 10:40:01AM -0700, Kees Cook wrote:
> On Thu, Oct 07, 2021 at 08:20:03PM +0300, Alexey Dobriyan wrote:
> > On Tue, Oct 05, 2021 at 07:31:09PM -0700, Kees Cook wrote:
> > > On Sun, Oct 03, 2021 at 03:11:24PM +0300, Alexey Dobriyan wrote:
> > > > Kernel assumes that ELF program headers are ordered by mapping address,
> > > > but doesn't enforce it. It is possible to make mapping size extremely huge
> > > > by simply shuffling first and last PT_LOAD segments.
> > > > 
> > > > As long as PT_LOAD segments do not overlap, it is silly to require
> > > > sorting by v_addr anyway because mmap() doesn't care.
> > > > 
> > > > Don't assume PT_LOAD segments are sorted and calculate min and max
> > > > addresses correctly.
> > > 
> > > Nice! Yes, this all make sense.
> > > 
> > > > 
> > > > Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
> > > > ---
> > > > 
> > > >  fs/binfmt_elf.c |   23 +++++++++++------------
> > > >  1 file changed, 11 insertions(+), 12 deletions(-)
> > > > 
> > > > --- a/fs/binfmt_elf.c
> > > > +++ b/fs/binfmt_elf.c
> > > > @@ -93,7 +93,7 @@ static int elf_core_dump(struct coredump_params *cprm);
> > > >  #define ELF_CORE_EFLAGS	0
> > > >  #endif
> > > >  
> > > > -#define ELF_PAGESTART(_v) ((_v) & ~(unsigned long)(ELF_MIN_ALIGN-1))
> > > > +#define ELF_PAGESTART(_v) ((_v) & ~(int)(ELF_MIN_ALIGN-1))
> > > 
> > > Errr, this I don't like. I assume this is because of the min() use
> > > below?
> > 
> > Yes, this is to shut up the warning.
> > 
> > The macro is slightly incorrect because "_v" can be either uint32_t or
> > uint64_t. But standard ALIGN macros are slightly incorrect too.
> 
> Right, but "int" is neither 64-sized nor unsigned. :P I would just leave
> this macro as-is.

"int" will be promoted to either "unsigned int" or to whatever 64-bit
ELF type is, it is enough to fix warnings, it will be sign extended
correctly.