From patchwork Wed Jun 2 15:58:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 453184 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 074AFC4708F for ; Wed, 2 Jun 2021 15:58:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E88256147D for ; Wed, 2 Jun 2021 15:58:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232236AbhFBP75 (ORCPT ); Wed, 2 Jun 2021 11:59:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231614AbhFBP74 (ORCPT ); Wed, 2 Jun 2021 11:59:56 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F7F9C061574; Wed, 2 Jun 2021 08:58:13 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622649492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WBUTfGNxNvSgHbeI2jsrGUtW90Hi09xpMn/ER3bz4aI=; b=Q1HwTSAnNmKjG5VfbJrVPl0BZWtHe38jyV+9UlcAlmzAPTv1hMSMJ/2x+pAdZrm8h2XLiT 7LFtuwAc1OXzxpcZiKKFr4fCJh8iFUuRZZV3dJBkvwrbuihHZG688gdgsF69czjqnZNpBY JyNMVZWiVP6xXCiOroqDBCPrN2uQqeKByOmKOt9fvAnjn26zzJmgQa4+JP9M/wjX1zRvCo oej198PKio4KyPds2VpNU8j021wiDJ3atzuBneAI9ISgpD2Y/0lHOsSxpCszq4s5hYLrRj OWi7hTI9dZqEZmcLKOcunI6XdT6rRrX1tpJceTQiVlE10f7OyBppl578PYm1zg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622649492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WBUTfGNxNvSgHbeI2jsrGUtW90Hi09xpMn/ER3bz4aI=; b=xvTHoFzERmxU1F7J1o/5k/I5q454qdshhO0o5mjdMinO9NI1Zm8xG/UHbadWCvqQF9VMJz zCFIjOThBTxNewDg== To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: [patch V2 2/8] x86/fpu: Prevent state corruption in __fpu__restore_sig() In-Reply-To: <20210602101618.462908825@linutronix.de> References: <20210602095543.149814064@linutronix.de> <20210602101618.462908825@linutronix.de> Date: Wed, 02 Jun 2021 17:58:11 +0200 Message-ID: <87y2bsz2b0.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Thomas Gleixner The non-compacted slowpath uses __copy_from_user() and copies the entire user buffer into the kernel buffer, verbatim. This means that the kernel buffer may now contain entirely invalid state on which XRSTOR will #GP. validate_user_xstate_header() can detect some of that corruption, but that leaves the onus on callers to clear the buffer. Prior to XSAVES support it was possible just to reinitialize the buffer, completely, but with supervisor states that is not longer possible as the buffer clearing code split got it backwards. Fixing that is possible, but not corrupting the state in the first place is more robust. Avoid corruption of the kernel XSAVE buffer by using copy_user_to_xstate() which validates the XSAVE header contents before copying the actual states to the kernel. copy_user_to_xstate() was previously only called for compacted-format kernel buffers, but it works for both compacted and non-compacted forms. Using it for the non-compacted form is slower because of multiple __copy_from_user() operations, but that cost is less important than robust code in an already slow path. [ Changelog polished by Dave Hansen ] Fixes: b860eb8dce59 ("x86/fpu/xstate: Define new functions for clearing fpregs and xstates") Reported-by: syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org --- V2: Removed the make validate_user_xstate_header() static hunks (Borislav) --- arch/x86/kernel/fpu/signal.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -405,14 +405,7 @@ static int __fpu__restore_sig(void __use if (use_xsave() && !fx_only) { u64 init_bv = xfeatures_mask_user() & ~user_xfeatures; - if (using_compacted_format()) { - ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx); - } else { - ret = __copy_from_user(&fpu->state.xsave, buf_fx, state_size); - - if (!ret && state_size > offsetof(struct xregs_state, header)) - ret = validate_user_xstate_header(&fpu->state.xsave.header); - } + ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx); if (ret) goto err_out; From patchwork Wed Jun 2 09:55:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 453988 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E723EC47098 for ; Wed, 2 Jun 2021 10:19:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3201613D0 for ; Wed, 2 Jun 2021 10:19:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233006AbhFBKVA (ORCPT ); Wed, 2 Jun 2021 06:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232707AbhFBKUJ (ORCPT ); Wed, 2 Jun 2021 06:20:09 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 235FEC061359; Wed, 2 Jun 2021 03:17:56 -0700 (PDT) Message-Id: <20210602101618.627715436@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622629075; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: references:references; bh=/Jk8BqEGhKI3fvl0aMu7kY8AMuceHqdD5GPwovljmik=; b=R7+6cM+S+Y4Io0oGaI+SSPodwPcKU8HkbqIm+03miq3MYPYI+iNzxGQK+qSkB2jTzXp9aj VeVOo56PI4AIi+doJV+4hrqsgaS6KUDSVEjXKUyJrWk99yb5kGTNwQbN1boeWWp4vNtSfG dXSsCTWrmMscH2swXmC95GU4I2DOB1JWizq5Et64dG4ULOZJN33+bkn5pVY4iL7mYA5gXO 2IMfDgRarZFwmnpCoPCyCT172SErFuo3uyQevhMh4ApqUqrTHdj4Al8De+8TMZ6F95x6gg XOuc/h+CViQ1fjy6+PeIUplK/R5gfBc3uy7Iy5fLJ2t3H4uK5cMY25yzlSB7qg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622629075; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: references:references; bh=/Jk8BqEGhKI3fvl0aMu7kY8AMuceHqdD5GPwovljmik=; b=o9y2d7a2f6HwbB6JGqTsbHFEee3QJODv2WX9nTv3szfRT7QTdO6m4xGmrxt/xB67bMD8Um RGY5kuvQgrzcNcAg== Date: Wed, 02 Jun 2021 11:55:46 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , stable@vger.kernel.org Subject: [patch 3/8] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer References: <20210602095543.149814064@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andy Lutomirski If XRSTOR fails due to sufficiently complicated paging errors (e.g. concurrent TLB invalidation), it may fault with #PF but still modify portions of the user extended state. If this happens in __fpu_restore_sig() with a victim task's FPU registers loaded and the task is preempted by the victim task, the victim task resumes with partially corrupt extended state. Invalidate the FPU registers when XRSTOR fails to prevent this scenario. Fixes: 1d731e731c4c ("x86/fpu: Add a fastpath to __fpu__restore_sig()") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org --- arch/x86/kernel/fpu/signal.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -369,6 +369,27 @@ static int __fpu__restore_sig(void __use fpregs_unlock(); return 0; } + + if (test_thread_flag(TIF_NEED_FPU_LOAD)) { + /* + * The FPU registers do not belong to current, and + * we just did an FPU restore operation, restricted + * to the user portion of the register file, and + * failed. In the event that the ucode was + * unfriendly and modified the registers at all, we + * need to make sure that we aren't corrupting an + * innocent non-current task's registers. + */ + __cpu_invalidate_fpregs_state(); + } else { + /* + * As above, we may have just clobbered current's + * user FPU state. We will either successfully + * load it or clear it below, so no action is + * required here. + */ + } + fpregs_unlock(); } else { /* From patchwork Wed Jun 2 09:55:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 453191 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9901CC4709A for ; Wed, 2 Jun 2021 10:19:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 81576613B8 for ; Wed, 2 Jun 2021 10:19:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233011AbhFBKVA (ORCPT ); Wed, 2 Jun 2021 06:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232708AbhFBKUJ (ORCPT ); Wed, 2 Jun 2021 06:20:09 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28093C06138F; Wed, 2 Jun 2021 03:17:58 -0700 (PDT) Message-Id: <20210602101618.736036127@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622629076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: references:references; bh=DGkVxXkLnQqzemQn1GsMwh95ap9O1ytCLq2NJcMCb3I=; b=eAeLX8vHolaZ0+wsT8BjXrLGP+R96GYKhxd2xQ0Sp4gjnhA5B4bA+laDKs2z8vQXw9mvhU Cwm4sn3M7pqiA7vQ1LAfC5WjnVVuZNYlLZ9zCfjKK7Mz1UJdydcwOdKRaMiPaVH4+YJo4l TuTPmGFZFSbdmetstRT+4UOUyumhlKUw7es6SLiI9ByvbXVzFEpcCaeP+iA5/l9lyNeX3o V60MaWJmtOKgNyBxR6UvFF/HJyJurvAVvnWvoIrpbI3TRdJ7Wlwuk3zRK59McOh59m26TX e+MwWhxhL7zTZ0Uhsj4q27poA1JlM6YFu/xbsO6JHoe77zLldMsuSHXEr75wAw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622629076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: references:references; bh=DGkVxXkLnQqzemQn1GsMwh95ap9O1ytCLq2NJcMCb3I=; b=4U4CsKexRwRa951J5YWB1+/oIyvk2Q1npmKhFlFHOSHHXnEMU7vPg8ZBla53uTxkObeer5 kzWykBpKH1WXlaCw== Date: Wed, 02 Jun 2021 11:55:47 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , stable@vger.kernel.org Subject: [patch 4/8] x86/fpu: Limit xstate copy size in xstateregs_set() References: <20210602095543.149814064@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org If the count argument is larger than the xstate size, this will happily copy beyond the end of xstate. Fixes: 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames for XSAVES") Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org --- arch/x86/kernel/fpu/regset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -117,7 +117,7 @@ int xstateregs_set(struct task_struct *t /* * A whole standard-format XSAVE buffer is needed: */ - if ((pos != 0) || (count < fpu_user_xstate_size)) + if (pos != 0 || count != fpu_user_xstate_size) return -EFAULT; xsave = &fpu->state.xsave;