From patchwork Sat Jun 5 23:47:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 455752 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=unavailable 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 D2A1FC47082 for ; Sun, 6 Jun 2021 00:32:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AF64161415 for ; Sun, 6 Jun 2021 00:32:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230090AbhFFAeL (ORCPT ); Sat, 5 Jun 2021 20:34:11 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:32968 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbhFFAeL (ORCPT ); Sat, 5 Jun 2021 20:34:11 -0400 Message-Id: <20210606001323.067157324@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622939541; 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=WBUTfGNxNvSgHbeI2jsrGUtW90Hi09xpMn/ER3bz4aI=; b=QjCMBXSplhThOU1uvhnkFuqIX//M1kbOsGmGhjQHRoT8NKFstACd5n/nm/POiNDt4tZTVV jnhGJPVOI0e07Cb/sXa3kZiXLj7qgdui3Miynem0mKEjvYpmg9+tgo2U8X4kj4Cx9suGF0 SVzC8tnULI9zM51FpQZGWR74FuSA84a+sa3oxFqqZ4HX5YWH9LyQUCMq5zr0QlPVbGQImF IkyE53NxcZ2z9rvLG5o5DNu26Qmm/Y7fHZKMH/SuVmRHNxtADANIWyd47OXf27H+jXUwqu uE+SZ4W/N6R+3mZYlXazQTmYhPC7dImcXhAfQgEOMCjM7EbMcRgVNDJYCMigmQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622939541; 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=WBUTfGNxNvSgHbeI2jsrGUtW90Hi09xpMn/ER3bz4aI=; b=A+FNEQPJumjdkbDH4Sp2SvWSmKCm28qOda6hpUo8zQiBL7nayVAIq4p4YHcEOkmXnMfh/4 fiK/mzSxiT3XQPCg== Date: Sun, 06 Jun 2021 01:47:44 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , Sebastian Andrzej Siewior , syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: [patch V2 02/14] x86/fpu: Prevent state corruption in __fpu__restore_sig() References: <20210605234742.712464974@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit 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 Reviewed-by: Borislav Petkov --- 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 Sat Jun 5 23:47:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Gleixner X-Patchwork-Id: 455257 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 C7DBFC48BC2 for ; Sun, 6 Jun 2021 00:32:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A697861415 for ; Sun, 6 Jun 2021 00:32:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230127AbhFFAeM (ORCPT ); Sat, 5 Jun 2021 20:34:12 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:32982 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230108AbhFFAeM (ORCPT ); Sat, 5 Jun 2021 20:34:12 -0400 Message-Id: <20210606001323.213119142@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622939542; 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=2VF+NDL8aHdPcXubNDnSyn1t+1GOHiiBi2fdFTg3nOM=; b=jiiyTGEKqvRF7f1KpsKdYkwiYL4Aal3GwsvEHPf1FjsQC7FKS2WNILCVOA+VHphUf6mmvw c3Jt9P5JWXNQ8nRXZp8ViJz6A6ZfYCIpdACQpiLURm3d0NOE2U4NvUxBLFWNHPb1AejRpq s3NnaGRmfLpDdSQLIkh1jXxKi+dHgbHOp4rkNZbo6fE8cU7cM4LGl8goY/k3CGpJzzhfww 7WSWjfd+pwKNbXFEgf8+KUDOq23sFEz6tOTQAtn3qWPxZv+bnh9QeXW+L7vzqDinNxbEM8 mk5q0JHS+yEgFMV8yOpJ+GOKom0QsZymfQIn8isjI8lOkU/apYl+hsC5ns8ceg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622939542; 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=2VF+NDL8aHdPcXubNDnSyn1t+1GOHiiBi2fdFTg3nOM=; b=AdKrueCoATMjJEwt8Hg+P15B3Q9oo77qvB98uiqKQ4eq/HD86VLeZFI2K/iH8nMdZtrz7a F0ZBCi2XRdXcgdAg== Date: Sun, 06 Jun 2021 01:47:45 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , Sebastian Andrzej Siewior , stable@vger.kernel.org Subject: [patch V2 03/14] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer References: <20210605234742.712464974@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 Both Intel and AMD consider it to be architecturally valid for XRSTOR to fail with #PF but nonetheless change the register state. The actual conditions under which this might occur are unclear [1], but it seems plausible that this might be triggered if one sibling thread unmaps a page and invalidates the shared TLB while another sibling thread is executing XRSTOR on the page in question. __fpu__restore_sig() can execute XRSTOR while the hardware registers are preserved on behalf of a different victim task (using the fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but modify the registers. If this happens, then there is a window in which __fpu__restore_sig() could schedule out and the victim task could schedule back in without reloading its own FPU registers. This would result in part of the FPU state that __fpu__restore_sig() was attempting to load leaking into the victim task's user-visible state. Invalidate preserved FPU registers on XRSTOR failure to prevent this situation from corrupting any state. [1] Frequent readers of the errata lists might imagine "complex microarchitectural conditions" 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 --- V2: Amend changelog - Borislav --- 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 Sat Jun 5 23:47: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: 455751 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 A1E3EC47082 for ; Sun, 6 Jun 2021 00:32:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8329561244 for ; Sun, 6 Jun 2021 00:32:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230161AbhFFAeP (ORCPT ); Sat, 5 Jun 2021 20:34:15 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:32984 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbhFFAeN (ORCPT ); Sat, 5 Jun 2021 20:34:13 -0400 Message-Id: <20210606001323.322361712@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622939543; 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=w2Xumy/rtK5QoqT4f2Tnf/imsYWuYuiwFBdOvm2F8TA=; b=uKd5jkxegS0loy+5ksBg1yiDzZ1BvmuYn9puJ5C0gup64PNY5LywHmFooEUBaftiCP9qgZ yP6Z0FqO7T66YlKBraGpoAH15tmh3JwkBVxdTC8YgQ1H+DfaSRFK54i4o1AxiWuY19v/Gq 9RoY7VW0WVS6TKYHsaiaOoQQ3rrLu51QFNBPAMOj/fX1xMeV8veQEM5GOMi4mxgySJ5mLm 2diqPv5499BK7MVRyqzfPLwNOuMA/6qyoH1hG/ZArNe15Jyowmwin6K8rPUsNNG/ymTkP+ 7UJiheEv7YEVYpBuA8nZMD3BLk2c6ZrQrDqOhH30qxvz5vEZv/Aur4Ex4gt+kQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622939543; 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=w2Xumy/rtK5QoqT4f2Tnf/imsYWuYuiwFBdOvm2F8TA=; b=DcAVMuvc3KAWjKKVWpO5nzDwiDBCcsCwVgJ+Bfs7/PCZOhX+ALKB8CXgTt7vn40JVMPWEg qJ4VNVWRtx9HJIDg== Date: Sun, 06 Jun 2021 01:47:46 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , Sebastian Andrzej Siewior , stable@vger.kernel.org Subject: [patch V2 04/14] x86/pkru: Make the fpinit state update work References: <20210605234742.712464974@linutronix.de> MIME-Version: 1.0 Content-transfer-encoding: 8-bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org It's unclear how this ever made any difference because init_fpstate.xsave.header.xfeatures is always 0 so get_xsave_addr() will always return a NULL pointer. Fix this by: - Creating a propagation function instead of several open coded instances and invoke it only once after the boot CPU has been initialized and from the debugfs file write function. - Set the PKRU feature bit in init_fpstate.xsave.header.xfeatures to make get_xsave_addr() work which allows to store the default value for real. - Having the feature bit set also gets rid of copy_init_pkru_to_fpregs() because now copy_init_fpstate_to_fpregs() already loads the default PKRU value. Fixes: a5eff7259790 ("x86/pkeys: Add PKRU value to init_fpstate") Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org --- V2: New patch --- arch/x86/include/asm/pkeys.h | 3 ++- arch/x86/kernel/cpu/bugs.c | 3 +++ arch/x86/kernel/cpu/common.c | 5 ----- arch/x86/kernel/fpu/core.c | 3 --- arch/x86/mm/pkeys.c | 31 ++++++++++++++----------------- include/linux/pkeys.h | 2 +- 6 files changed, 20 insertions(+), 27 deletions(-) --- a/arch/x86/include/asm/pkeys.h +++ b/arch/x86/include/asm/pkeys.h @@ -124,7 +124,8 @@ extern int arch_set_user_pkey_access(str unsigned long init_val); extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey, unsigned long init_val); -extern void copy_init_pkru_to_fpregs(void); + +extern void pkru_propagate_default(void); static inline int vma_pkey(struct vm_area_struct *vma) { --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -120,6 +121,8 @@ void __init check_bugs(void) arch_smt_update(); + pkru_propagate_default(); + #ifdef CONFIG_X86_32 /* * Check whether we are able to run this kernel safely on SMP. --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -465,8 +465,6 @@ static bool pku_disabled; static __always_inline void setup_pku(struct cpuinfo_x86 *c) { - struct pkru_state *pk; - /* check the boot processor, plus compile options for PKU: */ if (!cpu_feature_enabled(X86_FEATURE_PKU)) return; @@ -477,9 +475,6 @@ static __always_inline void setup_pku(st return; cr4_set_bits(X86_CR4_PKE); - pk = get_xsave_addr(&init_fpstate.xsave, XFEATURE_PKRU); - if (pk) - pk->pkru = init_pkru_value; /* * Setting X86_CR4_PKE will cause the X86_FEATURE_OSPKE * cpuid bit to be set. We need to ensure that we --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -348,9 +348,6 @@ static inline void copy_init_fpstate_to_ copy_kernel_to_fxregs(&init_fpstate.fxsave); else copy_kernel_to_fregs(&init_fpstate.fsave); - - if (boot_cpu_has(X86_FEATURE_OSPKE)) - copy_init_pkru_to_fpregs(); } /* --- a/arch/x86/mm/pkeys.c +++ b/arch/x86/mm/pkeys.c @@ -125,20 +125,20 @@ u32 init_pkru_value = PKRU_AD_KEY( 1) | PKRU_AD_KEY(10) | PKRU_AD_KEY(11) | PKRU_AD_KEY(12) | PKRU_AD_KEY(13) | PKRU_AD_KEY(14) | PKRU_AD_KEY(15); -/* - * Called from the FPU code when creating a fresh set of FPU - * registers. This is called from a very specific context where - * we know the FPU registers are safe for use and we can use PKRU - * directly. - */ -void copy_init_pkru_to_fpregs(void) +void pkru_propagate_default(void) { - u32 init_pkru_value_snapshot = READ_ONCE(init_pkru_value); + struct pkru_state *pk; + + if (!boot_cpu_has(X86_FEATURE_OSPKE)) + return; /* - * Override the PKRU state that came from 'init_fpstate' - * with the baseline from the process. + * Force XFEATURE_PKRU to be set in the header otherwise + * get_xsave_addr() does not work and it needs to be set + * to make XRSTOR(S) load it. */ - write_pkru(init_pkru_value_snapshot); + init_fpstate.xsave.header.xfeatures |= XFEATURE_MASK_PKRU; + pk = get_xsave_addr(&init_fpstate.xsave, XFEATURE_PKRU); + pk->pkru = READ_ONCE(init_pkru_value); } static ssize_t init_pkru_read_file(struct file *file, char __user *user_buf, @@ -154,10 +154,9 @@ static ssize_t init_pkru_read_file(struc static ssize_t init_pkru_write_file(struct file *file, const char __user *user_buf, size_t count, loff_t *ppos) { - struct pkru_state *pk; + u32 new_init_pkru; char buf[32]; ssize_t len; - u32 new_init_pkru; len = min(count, sizeof(buf) - 1); if (copy_from_user(buf, user_buf, len)) @@ -177,10 +176,8 @@ static ssize_t init_pkru_write_file(stru return -EINVAL; WRITE_ONCE(init_pkru_value, new_init_pkru); - pk = get_xsave_addr(&init_fpstate.xsave, XFEATURE_PKRU); - if (!pk) - return -EINVAL; - pk->pkru = new_init_pkru; + + pkru_propagate_default(); return count; } --- a/include/linux/pkeys.h +++ b/include/linux/pkeys.h @@ -44,7 +44,7 @@ static inline bool arch_pkeys_enabled(vo return false; } -static inline void copy_init_pkru_to_fpregs(void) +static inline void pkru_propagate_default(void) { } From patchwork Sat Jun 5 23:47: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: 455256 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 D834DC48BC2 for ; Sun, 6 Jun 2021 00:32:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B42AB6142A for ; Sun, 6 Jun 2021 00:32:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230163AbhFFAeP (ORCPT ); Sat, 5 Jun 2021 20:34:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230150AbhFFAeP (ORCPT ); Sat, 5 Jun 2021 20:34:15 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EB48C061766; Sat, 5 Jun 2021 17:32:26 -0700 (PDT) Message-Id: <20210606001323.429482447@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1622939545; 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=TwgOPkvlwEr2+9pco18ou68Nsdr0J21L+C1j7qoV5iywjlMDh0lZEtAvsATfT1Js0NBSFU LyX4yh/OfAelTxqLnZrj/tTMk+ts//KsoHaEw1MtCFm5jyrHQ1eKtJ3Kzwd7PnuGlOgNVe pkMTD4FrZkbnFaAdR4FZJCZeSkD8lfWQ/CeCPRglNqi5zCb4VO67sJq7VFSUE5LMldDH9I BDsrVF0m2do2wi9G2DfAoRbejpI5mhGxJuFkQ8bEOUEw31LLNWiuImPZsmeVRarO4utLgs OVFlXjrzb45bv67a6mzF8gCQzif6wBAorYFkUXRXQ3tACHbLMUjaeIgxm1u6yQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1622939545; 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=1PbhAnuPBzy6VVitiPdpa/DS6Dyam0MhPQtGE3LEEXUUiJhgY2MDJJL2SUiyBTKGUNZltD XmOLDa1/dA3j4JDA== Date: Sun, 06 Jun 2021 01:47:47 +0200 From: Thomas Gleixner To: LKML Cc: x86@kernel.org, Andy Lutomirski , Dave Hansen , Fenghua Yu , Tony Luck , Yu-cheng Yu , Sebastian Andrzej Siewior , stable@vger.kernel.org Subject: [patch V2 05/14] x86/fpu: Limit xstate copy size in xstateregs_set() References: <20210605234742.712464974@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;