Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp594154imu; Thu, 22 Nov 2018 02:24:18 -0800 (PST) X-Google-Smtp-Source: AFSGD/WTjQAvhK0oFDQq4qR0nupp11BfXfqfyHpDm+KroU+5VsPjnu8v/4kBCm07Hyd9p/YZKsPS X-Received: by 2002:a63:4d66:: with SMTP id n38mr9573508pgl.270.1542882258347; Thu, 22 Nov 2018 02:24:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542882258; cv=none; d=google.com; s=arc-20160816; b=gV1ByzmdqkN67VX5oXBwGYBiKPOGLNeRrz0uRO7++WqrylVhz/yxyP/dX+pqJNNjLf 3b98VX6zfqGuDq2/NVh8v5onGr5MMGrbGB+RmgMxhmv1ZsMSUwuW7cVEorKPBm2ACwDg j+WCdFRYNmBEtORJvQBd8NYqBFvVoyhp4xrGZwwwrkwb7RJHpuqxXCtezkIuGxE9BDTc o+XrBy2HzvEd2MI5ydoBhGu7q9FF9p55jkKZJYDWpcs00rxIPmPdtgWvQfTzHt0RoAXH Lkc1qwufQ03wqjiebu7W0CMImEz4NWA22Ddr02AiU2g1r9/7lGN5FHJVWZ5Nh4skAEeS ZPbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature; bh=OgQjcBDHCclIdPHfYWUmhF4tdnLyMDLHs8LLIVy4qdI=; b=AvCAsutMsbKkRje8d4Jv0mS5CQllf4pBXfnbTzT/t+f9o1xacTvEL2tv19ACjAn7yt 3cJMbwFrjqFCPQnxcwtsS1Zzx4x9jkPVWl27TMQcamcYTT6Y+5L6XKKtMdGEEWcjkhDm IG51PllO+NEfSRjJiKkTladx2wwNeZPGXJTj2SNP74oVv48Xeyl07sLW8FT5eRPCXy8q Gg/P9dr1uc9RlCpAigznfvgF64awP9JhEa+U0U0tF/rBmgQZKc0yTy9Oxq45bjpveqbr N98RnGuqbVIRgeguzO37sdIHZylquDNBEVBsvX9H1maaKOQvoZisek78KV8uFaU9F1xJ boDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rQdDd9Zi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i20si30537680pgh.187.2018.11.22.02.24.02; Thu, 22 Nov 2018 02:24:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rQdDd9Zi; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390485AbeKVJsB (ORCPT + 99 others); Thu, 22 Nov 2018 04:48:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:38716 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390454AbeKVJsB (ORCPT ); Thu, 22 Nov 2018 04:48:01 -0500 Received: from localhost (c-71-205-112-160.hsd1.co.comcast.net [71.205.112.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 84A2F20831; Wed, 21 Nov 2018 23:11:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542841891; bh=UDStHAw41c8BRZU+2Qd8Yc7LEmH5ARTYcG5AOJi8c8E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:In-Reply-To: References:From; b=rQdDd9Zisv72v07RgNfX8OQfOdtEbTcIsbU+zmIrYycA2jJw67vO6AAu9ZQ3B4Nxg o7CEuEJ3ZZDUWBXfc7D84seYxibmCb3etl2pn/uipHG5VlXK6seRayJb5rB/NRwzGj wIpCjLTPOATxHPyOUtCavUkFSu+012KtVZIzQ3vA= From: Andy Lutomirski To: x86@kernel.org Cc: LKML , Yu-cheng Yu , Dave Hansen , Peter Zijlstra , Borislav Petkov , Andy Lutomirski Subject: [PATCH v2 2/5] x86/fault: Don't try to recover from an implicit supervisor access Date: Wed, 21 Nov 2018 15:11:23 -0800 Message-Id: <9999f151d72ff352265f3274c5ab3a4105090f49.1542841400.git.luto@kernel.org> X-Mailer: git-send-email 2.17.2 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This avoids a situation in which we attempt to apply various fixups that are not intended to handle implicit supervisor accesses from user mode if we screw up in away that causes this type of fault. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 82881bc5feef..ca38bd0472f2 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -653,6 +653,15 @@ no_context(struct pt_regs *regs, unsigned long error_code, unsigned long flags; int sig; + if (user_mode(regs)) { + /* + * This is an implicit supervisor-mode access from user + * mode. Bypass all the kernel-mode recovery code and just + * OOPS. + */ + goto oops; + } + /* Are we prepared to handle this kernel fault? */ if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) { /* @@ -738,6 +747,7 @@ no_context(struct pt_regs *regs, unsigned long error_code, if (IS_ENABLED(CONFIG_EFI)) efi_recover_from_page_fault(address); +oops: /* * Oops. The kernel tried to access some bad page. We'll have to * terminate things with extreme prejudice: -- 2.17.2