From: Greg Kroah-Hartman Date: Tue, 17 May 2016 00:00:53 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.14.70~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ff59f1e29705c3e13aceba69f4afc59f14453b71;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: arm64-make-arch_randomize_brk-avoid-stack-area.patch --- diff --git a/queue-3.14/arm64-make-arch_randomize_brk-avoid-stack-area.patch b/queue-3.14/arm64-make-arch_randomize_brk-avoid-stack-area.patch new file mode 100644 index 00000000000..c1ebe9cce46 --- /dev/null +++ b/queue-3.14/arm64-make-arch_randomize_brk-avoid-stack-area.patch @@ -0,0 +1,121 @@ +From tixy@linaro.org Mon May 16 16:59:23 2016 +From: "Jon Medhurst (Tixy)" +Date: Tue, 10 May 2016 18:20:18 +0100 +Subject: arm64: Make arch_randomize_brk avoid stack area +To: stable@vger.kernel.org +Cc: Catalin Marinas , Kees Cook +Message-ID: <1462900818.3220.14.camel@linaro.org> + + +From: Jon Medhurst + +[As mentioned in the commit message, the problem this patch fixes can't +occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later., +but earlier kernel versions need this fix.] + +When a process is created, various address randomisations could end up +colluding to place the address of brk in the stack memory. This would +mean processes making small heap based memory allocations are in danger +of having them overwriting, or overwritten by, the stack. + +Another consequence, is that even for processes that make no use of +brk, the output of /proc/*/maps may show the stack area listed as +'[heap]' rather than '[stack]'. Apart from being misleading this causes +fatal errors with the Android run-time like: +"No [stack] line found in /proc/self/task/*/maps" + +To prevent this problem pick a limit for brk that allows for the stack's +memory. At the same time we remove randomize_base() as that was only +used by arch_randomize_brk(). + +Note, in practice, since commit d1fd836dcf00 ("mm: split ET_DYN ASLR +from mmap ASLR") this problem shouldn't occur because the address chosen +for loading binaries is well clear of the stack, however, prior to that +the problem does occur because of the following... + +The memory layout of a task is determined by arch_pick_mmap_layout. If +address randomisation is enabled (task has flag PF_RANDOMIZE) this sets +mmap_base to a random address at the top of task memory just below a +region calculated to allow for a stack which itself may have a random +base address. Any mmap operations that then happen which require an +address allocating will use the topdown allocation method, i.e. the +first allocated memory will be at the top of memory, just below the +area set aside for the stack. + +When a relocatable binary is loaded into a new process by +load_elf_binary and randomised address are enabled, it uses a +'load_bias' of zero, so that when mmap is called to create a memory +region for it, a new address is picked (address zero not being +available). As this is the first memory region in the task, it gets the +region just below the stack, as described previously. + +The loader then set's brk to the end of the elf data section, which will +be near the end of the loaded binary and then it calls +arch_randomize_brk. As this currently stands, this adds a random amount +to brk, which unfortunately may take it into the address range where the +stack lies. + +Testing: + +These changes have been tested on Linux 3.18 (where the collision of brk +and stack can happen) using 100000 invocations of a program [1] that can +display the offset of a process's brk... + +$for i in $(seq 100000); do ./aslr --report brk ; done + +This shows values of brk are evenly distributed over a 1GB range before +this change is applied. After this change the distribution shows a slope +where lower values for brk are more common and upper values have about +half the frequency of those. + +[1] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/2499/scripts/kernel-security/aslr/ + +Signed-off-by: Jon Medhurst +Acked-by: Kees Cook +Acked-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + + +I originally posted this to the ARM kernel list and arm64 maintainers, +see http://www.spinics.net/lists/arm-kernel/msg502238.html + + arch/arm64/kernel/process.c | 24 ++++++++++++++++++------ + 1 file changed, 18 insertions(+), 6 deletions(-) + +--- a/arch/arm64/kernel/process.c ++++ b/arch/arm64/kernel/process.c +@@ -350,15 +350,27 @@ unsigned long arch_align_stack(unsigned + return sp & ~0xf; + } + +-static unsigned long randomize_base(unsigned long base) ++unsigned long arch_randomize_brk(struct mm_struct *mm) + { ++ unsigned long base = mm->brk; + unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1; +- return randomize_range(base, range_end, 0) ? : base; +-} ++ unsigned long max_stack, range_limit; + +-unsigned long arch_randomize_brk(struct mm_struct *mm) +-{ +- return randomize_base(mm->brk); ++ /* ++ * Determine how much room we need to leave available for the stack. ++ * We limit this to a reasonable value, because extremely large or ++ * unlimited stacks are always going to bump up against brk at some ++ * point and we don't want to fail to randomise brk in those cases. ++ */ ++ max_stack = rlimit(RLIMIT_STACK); ++ if (max_stack > SZ_128M) ++ max_stack = SZ_128M; ++ ++ range_limit = mm->start_stack - max_stack - 1; ++ if (range_end > range_limit) ++ range_end = range_limit; ++ ++ return randomize_range(base, range_end, 0) ? : base; + } + + unsigned long randomize_et_dyn(unsigned long base) diff --git a/queue-3.14/series b/queue-3.14/series index c54dba4a7aa..1201b40ef01 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -14,3 +14,4 @@ net-fix-infoleak-in-rtnetlink.patch vsock-do-not-disconnect-socket-when-peer-has-shutdown-send-only.patch net-bridge-fix-old-ioctl-unlocked-net-device-walk.patch net-fix-a-kernel-infoleak-in-x25-module.patch +arm64-make-arch_randomize_brk-avoid-stack-area.patch