From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763563AbdEXO1Z (ORCPT ); Wed, 24 May 2017 10:27:25 -0400 Received: from terminus.zytor.com ([65.50.211.136]:35565 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760557AbdEXO1V (ORCPT ); Wed, 24 May 2017 10:27:21 -0400 Date: Wed, 24 May 2017 07:25:09 -0700 From: tip-bot for Mateusz Jurczyk Message-ID: Cc: mjurczyk@google.com, linux-kernel@vger.kernel.org, hpa@zytor.com, bp@suse.de, luto@kernel.org, mingo@kernel.org, tglx@linutronix.de Reply-To: tglx@linutronix.de, luto@kernel.org, mingo@kernel.org, mjurczyk@google.com, hpa@zytor.com, linux-kernel@vger.kernel.org, bp@suse.de In-Reply-To: <20170524135500.27223-1-mjurczyk@google.com> References: <20170524135500.27223-1-mjurczyk@google.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/urgent] x86/alternatives: Prevent uninitialized stack byte read in apply_alternatives() Git-Commit-ID: fc152d22d6e9fac95a9a990e6c29510bdf1b9425 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: fc152d22d6e9fac95a9a990e6c29510bdf1b9425 Gitweb: http://git.kernel.org/tip/fc152d22d6e9fac95a9a990e6c29510bdf1b9425 Author: Mateusz Jurczyk AuthorDate: Wed, 24 May 2017 15:55:00 +0200 Committer: Thomas Gleixner CommitDate: Wed, 24 May 2017 16:18:12 +0200 x86/alternatives: Prevent uninitialized stack byte read in apply_alternatives() In the current form of the code, if a->replacementlen is 0, the reference to *insnbuf for comparison touches potentially garbage memory. While it doesn't affect the execution flow due to the subsequent a->replacementlen comparison, it is (rightly) detected as use of uninitialized memory by a runtime instrumentation currently under my development, and could be detected as such by other tools in the future, too (e.g. KMSAN). Fix the "false-positive" by reordering the conditions to first check the replacement instruction length before referencing specific opcode bytes. Signed-off-by: Mateusz Jurczyk Reviewed-by: Borislav Petkov Cc: Andy Lutomirski Link: http://lkml.kernel.org/r/20170524135500.27223-1-mjurczyk@google.com Signed-off-by: Thomas Gleixner --- arch/x86/kernel/alternative.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c index c5b8f76..32e14d1 100644 --- a/arch/x86/kernel/alternative.c +++ b/arch/x86/kernel/alternative.c @@ -409,8 +409,13 @@ void __init_or_module noinline apply_alternatives(struct alt_instr *start, memcpy(insnbuf, replacement, a->replacementlen); insnbuf_sz = a->replacementlen; - /* 0xe8 is a relative jump; fix the offset. */ - if (*insnbuf == 0xe8 && a->replacementlen == 5) { + /* + * 0xe8 is a relative jump; fix the offset. + * + * Instruction length is checked before the opcode to avoid + * accessing uninitialized bytes for zero-length replacements. + */ + if (a->replacementlen == 5 && *insnbuf == 0xe8) { *(s32 *)(insnbuf + 1) += replacement - instr; DPRINTK("Fix CALL offset: 0x%x, CALL 0x%lx", *(s32 *)(insnbuf + 1),