From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:38310 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752380AbdIRG5i (ORCPT ); Mon, 18 Sep 2017 02:57:38 -0400 Subject: Patch "x86/fsgsbase/64: Fully initialize FS and GS state in start_thread_common" has been added to the 4.13-stable tree To: luto@kernel.org, bp@alien8.de, bpetkov@suse.de, brgerst@gmail.com, chang.seok.bae@intel.com, dvlasenk@redhat.com, gregkh@linuxfoundation.org, hpa@zytor.com, jpoimboe@redhat.com, mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de, torvalds@linux-foundation.org Cc: , From: Date: Mon, 18 Sep 2017 08:57:44 +0200 Message-ID: <150571786496255@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled x86/fsgsbase/64: Fully initialize FS and GS state in start_thread_common to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: x86-fsgsbase-64-fully-initialize-fs-and-gs-state-in-start_thread_common.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 767d035d838f4fd6b5a5bbd7a3f6d293b7f65a49 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Tue, 1 Aug 2017 07:11:34 -0700 Subject: x86/fsgsbase/64: Fully initialize FS and GS state in start_thread_common From: Andy Lutomirski commit 767d035d838f4fd6b5a5bbd7a3f6d293b7f65a49 upstream. execve used to leak FSBASE and GSBASE on AMD CPUs. Fix it. The security impact of this bug is small but not quite zero -- it could weaken ASLR when a privileged task execs a less privileged program, but only if program changed bitness across the exec, or the child binary was highly unusual or actively malicious. A child program that was compromised after the exec would not have access to the leaked base. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Brian Gerst Cc: Chang Seok Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/process_64.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -229,10 +229,19 @@ start_thread_common(struct pt_regs *regs unsigned long new_sp, unsigned int _cs, unsigned int _ss, unsigned int _ds) { + WARN_ON_ONCE(regs != current_pt_regs()); + + if (static_cpu_has(X86_BUG_NULL_SEG)) { + /* Loading zero below won't clear the base. */ + loadsegment(fs, __USER_DS); + load_gs_index(__USER_DS); + } + loadsegment(fs, 0); loadsegment(es, _ds); loadsegment(ds, _ds); load_gs_index(0); + regs->ip = new_ip; regs->sp = new_sp; regs->cs = _cs; Patches currently in stable-queue which might be from luto@kernel.org are queue-4.13/x86-switch_to-64-rewrite-fs-gs-switching-yet-again-to-fix-amd-cpus.patch queue-4.13/x86-fsgsbase-64-fully-initialize-fs-and-gs-state-in-start_thread_common.patch queue-4.13/x86-fsgsbase-64-report-fsbase-and-gsbase-correctly-in-core-dumps.patch queue-4.13/x86-mm-mm-hwpoison-clear-present-bit-for-kernel-1-1-mappings-of-poison-pages.patch