linux-stable.git/fs/binfmt_elf.c, branch linux-3.16.y

fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info()

2020-06-11T18:05:58+00:00

commit 1d605416fb7175e1adf094251466caa52093b413 upstream.

KMSAN reported uninitialized data being written to disk when dumping
core.  As a result, several kilobytes of kmalloc memory may be written
to the core file and then read by a non-privileged user.

Reported-by: sam 
Signed-off-by: Alexander Potapenko 
Signed-off-by: Andrew Morton 
Acked-by: Kees Cook 
Cc: Al Viro 
Cc: Alexey Dobriyan 
Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com
Link: https://github.com/google/kmsan/issues/76
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

binfmt_elf: switch to new creds when switching to new mm

2019-05-02T20:42:07+00:00

commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46 upstream.

We used to delay switching to the new credentials until after we had
mapped the executable (and possible elf interpreter).  That was kind of
odd to begin with, since the new executable will actually then _run_
with the new creds, but whatever.

The bigger problem was that we also want to make sure that we turn off
prof events and tracing before we start mapping the new executable
state.  So while this is a cleanup, it's also a fix for a possible
information leak.

Reported-by: Robert Święcki 
Tested-by: Peter Zijlstra 
Acked-by: David Howells 
Acked-by: Oleg Nesterov 
Acked-by: Andy Lutomirski 
Acked-by: Eric W. Biederman 
Cc: Willy Tarreau 
Cc: Kees Cook 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

binfmt_elf: Fix missing SIGKILL for empty PIE

2019-05-02T20:42:06+00:00

Commit ea08dc5191d9 "fs/binfmt_elf.c: fix bug in loading of PIE
binaries", which was a backport of commit a87938b2e246 upstream,
added a new failure path to load_elf_binary().

Before commit 19d860a140be "handle suicide on late failure exits in
execve() in search_binary_handler()", load_elf_binary() wass
responsible for sending a fatal signal to the task in case of an error
after flushing the old executable.  Add that to the new failure path.

Signed-off-by: Ben Hutchings

binfmt_elf: Respect error return from `regset->active'

2018-12-16T22:08:17+00:00

commit 2f819db565e82e5f73cd42b39925098986693378 upstream.

The regset API documented in  defines -ENODEV as the
result of the `->active' handler to be used where the feature requested
is not available on the hardware found.  However code handling core file
note generation in `fill_thread_core_info' interpretes any non-zero
result from the `->active' handler as the regset requested being active.
Consequently processing continues (and hopefully gracefully fails later
on) rather than being abandoned right away for the regset requested.

Fix the problem then by making the code proceed only if a positive
result is returned from the `->active' handler.

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Paul Burton 
Fixes: 4206d3aa1978 ("elf core dump: notes user_regset")
Patchwork: https://patchwork.linux-mips.org/patch/19332/
Cc: Alexander Viro 
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ben Hutchings

fs, elf: make sure to page align bss in load_elf_library

2018-11-20T18:05:41+00:00

commit 24962af7e1041b7e50c1bc71d8d10dc678c556b5 upstream.

The current code does not make sure to page align bss before calling
vm_brk(), and this can lead to a VM_BUG_ON() in __mm_populate() due to
the requested lenght not being correctly aligned.

Let us make sure to align it properly.

Kees: only applicable to CONFIG_USELIB kernels: 32-bit and configured
for libc5.

Link: http://lkml.kernel.org/r/20180705145539.9627-1-osalvador@techadventures.net
Signed-off-by: Oscar Salvador 
Reported-by: syzbot+5dcb560fe12aa5091c06@syzkaller.appspotmail.com
Tested-by: Tetsuo Handa 
Acked-by: Kees Cook 
Cc: Michal Hocko 
Cc: Nicolas Pitre 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

binfmt_elf: fix calculations for bss padding

2018-11-20T18:05:40+00:00

commit 0036d1f7eb95bcc52977f15507f00dd07018e7e2 upstream.

A double-bug exists in the bss calculation code, where an overflow can
happen in the "last_bss - elf_bss" calculation, but vm_brk internally
aligns the argument, underflowing it, wrapping back around safe.  We
shouldn't depend on these bugs staying in sync, so this cleans up the
bss padding handling to avoid the overflow.

This moves the bss padzero() before the last_bss > elf_bss case, since
the zero-filling of the ELF_PAGE should have nothing to do with the
relationship of last_bss and elf_bss: any trailing portion should be
zeroed, and a zero size is already handled by padzero().

Then it handles the math on elf_bss vs last_bss correctly.  These need
to both be ELF_PAGE aligned to get the comparison correct, since that's
the expected granularity of the mappings.  Since elf_bss already had
alignment-based padding happen in padzero(), the "start" of the new
vm_brk() should be moved forward as done in the original code.  However,
since the "end" of the vm_brk() area will already become PAGE_ALIGNed in
vm_brk() then last_bss should get aligned here to avoid hiding it as a
side-effect.

Additionally makes a cosmetic change to the initial last_bss calculation
so it's easier to read in comparison to the load_addr calculation above
it (i.e.  the only difference is p_filesz vs p_memsz).

Link: http://lkml.kernel.org/r/1468014494-25291-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook 
Reported-by: Hector Marco-Gisbert 
Cc: Ismael Ripoll Ripoll 
Cc: Alexander Viro 
Cc: "Kirill A. Shutemov" 
Cc: Oleg Nesterov 
Cc: Chen Gang 
Cc: Michal Hocko 
Cc: Konstantin Khlebnikov 
Cc: Andrea Arcangeli 
Cc: Andrey Ryabinin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

mm, elf: handle vm_brk error

2018-11-20T18:05:40+00:00

commit ecc2bc8ac03884266cf73f8a2a42b911465b2fbc upstream.

load_elf_library doesn't handle vm_brk failure although nothing really
indicates it cannot do that because the function is allowed to fail due
to vm_mmap failures already.  This might be not a problem now but later
patch will make vm_brk killable (resp.  mmap_sem for write waiting will
become killable) and so the failure will be more probable.

Signed-off-by: Michal Hocko 
Acked-by: Vlastimil Babka 
Cc: Alexander Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

binfmt_elf: Don't clobber passed executable's file header

2015-12-13T17:49:24+00:00

commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream.

Do not clobber the buffer space passed from `search_binary_handler' and
originally preloaded by `prepare_binprm' with the executable's file
header by overwriting it with its interpreter's file header.  Instead
keep the buffer space intact and directly use the data structure locally
allocated for the interpreter's file header, fixing a bug introduced in
2.1.14 with loadable module support (linux-mips.org commit beb11695
[Import of Linux/MIPS 2.1.14], predating kernel.org repo's history).
Adjust the amount of data read from the interpreter's file accordingly.

This was not an issue before loadable module support, because back then
`load_elf_binary' was executed only once for a given ELF executable,
whether the function succeeded or failed.

With loadable module support supported and enabled, upon a failure of
`load_elf_binary' -- which may for example be caused by architecture
code rejecting an executable due to a missing hardware feature requested
in the file header -- a module load is attempted and then the function
reexecuted by `search_binary_handler'.  With the executable's file
header replaced with its interpreter's file header the executable can
then be erroneously accepted in this subsequent attempt.

Signed-off-by: Maciej W. Rozycki 
Signed-off-by: Al Viro 
Signed-off-by: Luis Henriques

fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

2015-06-03T13:30:08+00:00

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan 
Cc: Michael Davidson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Luis Henriques

fs/binfmt_elf.c: fix bug in loading of PIE binaries

2015-05-06T09:24:24+00:00

commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 upstream.

With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down
address allocation strategy, load_elf_binary() will attempt to map a PIE
binary into an address range immediately below mm->mmap_base.

Unfortunately, load_elf_ binary() does not take account of the need to
allocate sufficient space for the entire binary which means that, while
the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent
PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are
that is supposed to be the "gap" between the stack and the binary.

Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this
means that binaries with large data segments > 128MB can end up mapping
part of their data segment over their stack resulting in corruption of the
stack (and the data segment once the binary starts to run).

Any PIE binary with a data segment > 128MB is vulnerable to this although
address randomization means that the actual gap between the stack and the
end of the binary is normally greater than 128MB.  The larger the data
segment of the binary the higher the probability of failure.

Fix this by calculating the total size of the binary in the same way as
load_elf_interp().

Signed-off-by: Michael Davidson 
Cc: Alexander Viro 
Cc: Jiri Kosina 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Luis Henriques