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

[Alexey Dobriyan <adobriyan@gmail.com>]

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@gmail.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.