linux-kernel - Re: linux-next: build failure after merge of the akpm-current tree

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 17 Apr 2019 17:28:39 -0500
From:   Kees Cook <keescook@...omium.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: linux-next: build failure after merge of the akpm-current tree

On Wed, Apr 17, 2019 at 5:22 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Wed, Apr 17, 2019 at 1:53 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > Hi Andrew,
> >
> > After merging the akpm-current tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > fs/binfmt_elf.c: In function 'load_elf_binary':
> > fs/binfmt_elf.c:1140:7: error: 'elf_interpreter' undeclared (first use in this function); did you mean 'interpreter'?
> >   if (!elf_interpreter)
> >        ^~~~~~~~~~~~~~~
> >        interpreter
>
> static int load_elf_binary(struct linux_binprm *bprm)
> {
> ...
>         char * elf_interpreter = NULL;
>
> This is _absolutely_ a valid variable.

I saw a 0day report[1] as well on MIPS for this. Neither have I been
able to reproduce, though. I'm wondering if, due to the misplaced
kfree() that has existed for a while, if some kind of weird scoping is
happening.

What compiler are you using?

[1] https://lists.01.org/pipermail/kbuild-all/2019-April/060058.html

>
> >
> >
> > Caused by commit
> >
> >   3ebf0dd657ce ("fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec")
> >
> > interacting with commit
> >
> >   a34f642bccf1 ("fs/binfmt_elf.c: free PT_INTERP filename ASAP")
> >
> > I have applied the following patch for today.
> >
> > From: Stephen Rothwell <sfr@...b.auug.org.au>
> > Date: Wed, 17 Apr 2019 16:48:29 +1000
> > Subject: [PATCH] fix "fs/binfmt_elf.c: move brk out of mmap when doing direct loader exec"
> >
> > Signed-off-by: Stephen Rothwell <sfr@...b.auug.org.au>
> > ---
> >  fs/binfmt_elf.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> > index b3bbe6bca499..fe5668a1bbaa 100644
> > --- a/fs/binfmt_elf.c
> > +++ b/fs/binfmt_elf.c
> > @@ -1137,7 +1137,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> >          * collide early with the stack growing down), and into the unused
> >          * ELF_ET_DYN_BASE region.
> >          */
> > -       if (!elf_interpreter)
> > +       if (!interpreter)
>
> No, this is very wrong and will, I think, cause all PIE binaries to fail to run.

I may be wrong: I think this will cause all static binaries to see
their brk moved very unexpectedly. All static PIE binaries will fail?





--
Kees Cook