Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 7 Oct 2021 21:31:40 +0300
From:   Alexey Dobriyan <adobriyan@gmail.com>
To:     Kees Cook <keescook@chromium.org>
Cc:     akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ELF: fix overflow in total mapping size calculation
Message-ID: <YV89DPAbNxjZfPY+@localhost.localdomain>
References: <YVmd7D0M6G/DcP4O@localhost.localdomain>
 <202110051929.37279B6B4A@keescook>
 <YV8sQ5vhD+V6XLXx@localhost.localdomain>
 <202110071038.B589687@keescook>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <202110071038.B589687@keescook>
Precedence: bulk

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.