From: Greg Kroah-Hartman Date: Tue, 17 May 2016 20:32:16 +0000 (-0700) Subject: remove queue-3.14/arm64-make-arch_randomize_brk-avoid-stack-area.patch X-Git-Tag: v3.14.70~2 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=10ff835227fac5e47fc4746c7609509d2bc92e73;p=thirdparty%2Fkernel%2Fstable-queue.git remove queue-3.14/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 deleted file mode 100644 index c1ebe9cce46..00000000000 --- a/queue-3.14/arm64-make-arch_randomize_brk-avoid-stack-area.patch +++ /dev/null @@ -1,121 +0,0 @@ -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 1201b40ef01..c54dba4a7aa 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -14,4 +14,3 @@ 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