linux-kernel - Re: [tip:x86/boot] x86/KASLR: Fix boot crash with certain memory configurations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160710090953.GA2512@x1.redhat.com>
Date:	Sun, 10 Jul 2016 17:09:53 +0800
From:	Baoquan He <bhe@...hat.com>
To:	peterz@...radead.org, hpa@...or.com, keescook@...omium.org,
	xiaolong.ye@...el.com, linux-kernel@...r.kernel.org,
	mingo@...nel.org, tglx@...utronix.de, torvalds@...ux-foundation.org
Cc:	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/boot] x86/KASLR: Fix boot crash with certain memory
 configurations

Hi Ingo,

I am sorry the previous post didn't contain formal patch log. I made a
new one as below. The boot crash could not only happen with certain
memory. Because of this code bug the regions which need be avoided like
the zipped kernel with its unzipping running code, initrd, kernel
command line could be corrupted if mem_avoid_overlap() can't find the
overlap region with the lowest address. But it's very lucky that
Xiaolong's system which has only 300M memory can always reproduce it.
I checked the boog log and found on his system no any other slot can be
chosen except for the original one. If we have a system with large memory
it may not be easy to hit it, at least with low probability since there
are many candidate slots.

>From 8f48aa39f3e49f9c1a9bb8ee61547dda7c2c05c3 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@...hat.com>
Date: Fri, 1 Jul 2016 15:34:40 +0800
Subject: [PATCH] x86/KASLR: Fix boot crash caused by wrongly chosen kernel
 physical address

System halted with the separate randomization code applied. With debug printing
we got the reason that the chosen kernel physical address randomly is overlapped
with input dada. So input data and its running space must be corrupted during
decompressing kernel, then boot crash happened.

The root cause is that in function mem_avoid_overlap() local variable 'earliest'
is not updated correctly. Function mem_avoid_overlap is used to find the overlap
region with the lowest address, and 'earliest' is used to track the lowest address.
Decompressing kernel could step into those regions which need be avoided if we
didn't handle these overlap region correctly. So fix the code bug now.

Signed-off-by: Baoquan He <bhe@...hat.com>
---
 arch/x86/boot/compressed/kaslr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 304c5c3..8e1fdf7 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -285,6 +285,7 @@ static bool mem_avoid_overlap(struct mem_vector *img,
 		if (mem_overlaps(img, &mem_avoid[i]) &&
 		    mem_avoid[i].start < earliest) {
 			*overlap = mem_avoid[i];
+			earliest = overlap->start;
 			is_overlapping = true;
 		}
 	}
@@ -299,6 +300,7 @@ static bool mem_avoid_overlap(struct mem_vector *img,

 		if (mem_overlaps(img, &avoid) && (avoid.start < earliest)) {
 			*overlap = avoid;
+			earliest = overlap->start;
 			is_overlapping = true;
 		}

-- 
2.5.5