From patchwork Fri Feb 23 10:42:04 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jinpu Wang X-Patchwork-Id: 10237445 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 00DE4602DC for ; Fri, 23 Feb 2018 11:25:29 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E95E829505 for ; Fri, 23 Feb 2018 11:25:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DC9D529537; Fri, 23 Feb 2018 11:25:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id D148D29530 for ; Fri, 23 Feb 2018 11:25:27 +0000 (UTC) Received: (qmail 17520 invoked by uid 550); 23 Feb 2018 11:22:53 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Delivered-To: moderator for kernel-hardening@lists.openwall.com Received: (qmail 5349 invoked from network); 23 Feb 2018 10:42:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=profitbricks-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=oALMBMDNZ3B/rGXO7LE5spTVztiOZ8d+1d1kHEEWpeo=; b=bTvd+4OU648smO/8mqTP3KAWOH5X5vt5IwGFaECYVOZj4ia0zivFdXZ0I0NPWnT1Iz eC8xKkh1r+6h/mgWdGgILXALPKfnnG/m0qrJgE184rUoXvbYU91AKnvtP4xuSjwQd+Xu VyRK6oaZ16I1J4wlmXHJHCvnSCaZ1jXiA6q3pSzLeNmNdEbIbm3YiIWO/Pej3LuB2YTc M+vIoKhNkAox19SFxyRxLA9IbzIHoJHbreST4d9rmgrRLWHFXKyA93GM3dxHUMDNHqnt DEKn8l64Cp8KIHq7s1qAF45A5TuYH/zaKQlMqKWRfU13CeFgYFTActg17gmt+d5Vd3Jv 0fHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=oALMBMDNZ3B/rGXO7LE5spTVztiOZ8d+1d1kHEEWpeo=; b=ZmMu0iPGra+q7el0KEE7PC35QHb0qeJp0e2H0yN+BTz962pDSul/PRWWtrg5J5ycm0 8jCSQWsvCb1Cnlu3aRGOhdhTJ69Mxt0ylzJ4rUUv1eUpw8y5Edd1DafL3DsIq24aNCQH 9WwCNnLjbzdQrKAZcE1f9WshpkP/8MJewJAPNJ/RXWpeAug8Bx2r2xE6rXf2Cghzj9rl U/Fh9R6pZcZv/Nvxg6wc/KGSyGaa5X66OXXPjcRniHtbo//CVxKJacurTRKIHl5ibwVz JDT/P7pyTU7VKLb8++sZTcvmfA5ynzUVxoP5Yk4nWASSDl++qiHrY7Y6fReq50z57vjO MSRA== X-Gm-Message-State: APf1xPCq1H6rLgyCft8p0bTwgJPvqWtrh1bEAktg+xHIIyAFWOaDC4Wh 7yXrqGyNaR2Ve4bCztZ7NNkC8ZN0umE= X-Google-Smtp-Source: AH8x227v3pTKdH7mefc2WmADYW6lPwhsPrZk/LhNygWBJukJy3n7LxoMucBuWoa9teITergTd0wVyQ== X-Received: by 10.28.17.17 with SMTP id 17mr1386673wmr.123.1519382558455; Fri, 23 Feb 2018 02:42:38 -0800 (PST) From: Jack Wang X-Google-Original-From: Jack Wang To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: Dan Williams , Thomas Gleixner , linux-arch@vger.kernel.org, kernel-hardening@lists.openwall.com, Andy Lutomirski , alan@linux.intel.com, David Woodhouse , Jack Wang Subject: [stable 4.4 15/29] x86/syscall: Sanitize syscall table de-references under speculation Date: Fri, 23 Feb 2018 11:42:04 +0100 Message-Id: <1519382538-15143-16-git-send-email-jinpu.wangl@profitbricks.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1519382538-15143-1-git-send-email-jinpu.wangl@profitbricks.com> References: <1519382538-15143-1-git-send-email-jinpu.wangl@profitbricks.com> X-Virus-Scanned: ClamAV using ClamSMTP From: Dan Williams (cherry picked from commit 2fbd7af5af8665d18bcefae3e9700be07e22b681) The syscall table base is a user controlled function pointer in kernel space. Use array_index_nospec() to prevent any out of bounds speculation. While retpoline prevents speculating into a userspace directed target it does not stop the pointer de-reference, the concern is leaking memory relative to the syscall table base, by observing instruction cache behavior. Reported-by: Linus Torvalds Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Andy Lutomirski Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727417984.33451.1216731042505722161.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman [jwang: port to 4.4, no syscall_64] Signed-off-by: Jack Wang --- arch/x86/entry/common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c index 1a4477c..b5eb1cc 100644 --- a/arch/x86/entry/common.c +++ b/arch/x86/entry/common.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include @@ -381,6 +382,7 @@ __always_inline void do_syscall_32_irqs_on(struct pt_regs *regs) } if (likely(nr < IA32_NR_syscalls)) { + nr = array_index_nospec(nr, IA32_NR_syscalls); /* * It's possible that a 32-bit syscall implementation * takes a 64-bit parameter but nonetheless assumes that