From: Greg Kroah-Hartman Date: Thu, 19 Sep 2019 20:09:18 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.4.194~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=073adaf465760d2fe9c82702aa84cd4174d9aa6b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch --- diff --git a/queue-4.19/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch b/queue-4.19/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch new file mode 100644 index 00000000000..e5c68c4befa --- /dev/null +++ b/queue-4.19/binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch @@ -0,0 +1,105 @@ +From bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Tue, 14 May 2019 15:43:57 -0700 +Subject: binfmt_elf: move brk out of mmap when doing direct loader exec + +From: Kees Cook + +commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream. + +Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"), +made changes in the rare case when the ELF loader was directly invoked +(e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of +the loader), by moving into the mmap region to avoid both ET_EXEC and +PIE binaries. This had the effect of also moving the brk region into +mmap, which could lead to the stack and brk being arbitrarily close to +each other. An unlucky process wouldn't get its requested stack size +and stack allocations could end up scribbling on the heap. + +This is illustrated here. In the case of using the loader directly, brk +(so helpfully identified as "[heap]") is allocated with the _loader_ not +the binary. For example, with ASLR entirely disabled, you can see this +more clearly: + +$ /bin/cat /proc/self/maps +555555554000-55555555c000 r-xp 00000000 ... /bin/cat +55555575b000-55555575c000 r--p 00007000 ... /bin/cat +55555575c000-55555575d000 rw-p 00008000 ... /bin/cat +55555575d000-55555577e000 rw-p 00000000 ... [heap] +... +7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar] +7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso] +7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so +7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so +7ffff7ffe000-7ffff7fff000 rw-p 00000000 ... +7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack] + +$ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps +... +7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat +7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat +7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat +7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat +7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so +7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ... +7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar] +7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso] +7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so +7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so +7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap] +7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack] + +The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since +nothing is there in the direct loader case (and ET_EXEC is still far +away at 0x400000). Anything that ran before should still work (i.e. +the ultimately-launched binary already had the brk very far from its +text, so this should be no different from a COMPAT_BRK standpoint). The +only risk I see here is that if someone started to suddenly depend on +the entire memory space lower than the mmap region being available when +launching binaries via a direct loader execs which seems highly +unlikely, I'd hope: this would mean a binary would _not_ work when +exec()ed normally. + +(Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION +when randomization is turned on.) + +Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast +Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com +Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") +Signed-off-by: Kees Cook +Reported-by: Ali Saidi +Cc: Ali Saidi +Cc: Guenter Roeck +Cc: Michal Hocko +Cc: Matthew Wilcox +Cc: Thomas Gleixner +Cc: Jann Horn +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Cc: Frank van der Linden +Signed-off-by: Greg Kroah-Hartman + +--- + fs/binfmt_elf.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/binfmt_elf.c ++++ b/fs/binfmt_elf.c +@@ -1137,6 +1137,17 @@ static int load_elf_binary(struct linux_ + current->mm->start_stack = bprm->p; + + if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1)) { ++ /* ++ * For architectures with ELF randomization, when executing ++ * a loader directly (i.e. no interpreter listed in ELF ++ * headers), move the brk area out of the mmap region ++ * (since it grows up, and may collide early with the stack ++ * growing down), and into the unused ELF_ET_DYN_BASE region. ++ */ ++ if (IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) && !interpreter) ++ current->mm->brk = current->mm->start_brk = ++ ELF_ET_DYN_BASE; ++ + current->mm->brk = current->mm->start_brk = + arch_randomize_brk(current->mm); + #ifdef compat_brk_randomized diff --git a/queue-4.19/series b/queue-4.19/series index 49e2524f467..67e7563bc58 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -74,3 +74,4 @@ iommu-amd-fix-race-in-increase_address_space.patch pci-kirin-fix-section-mismatch-warning.patch ovl-fix-regression-caused-by-overlapping-layers-detection.patch floppy-fix-usercopy-direction.patch +binfmt_elf-move-brk-out-of-mmap-when-doing-direct-loader-exec.patch