The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From efa165504943f2128d50f63de0c02faf6dcceb0d Mon Sep 17 00:00:00 2001
From: Thomas Gleixner tglx@linutronix.de Date: Wed, 9 Jun 2021 21:18:00 +0200 Subject: [PATCH] x86/fpu: Reset state for all signal restore failures
If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the function just returns but does not clear the FPU state as it does for all other fatal failures.
Clear the FPU state for these failures as well.
Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels") Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Borislav Petkov bp@suse.de Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index 4ab9aeb9a963..ec3ae3054792 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -307,13 +307,17 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) return 0; }
- if (!access_ok(buf, size)) - return -EACCES; + if (!access_ok(buf, size)) { + ret = -EACCES; + goto out; + }
- if (!static_cpu_has(X86_FEATURE_FPU)) - return fpregs_soft_set(current, NULL, - 0, sizeof(struct user_i387_ia32_struct), - NULL, buf) != 0; + if (!static_cpu_has(X86_FEATURE_FPU)) { + ret = fpregs_soft_set(current, NULL, 0, + sizeof(struct user_i387_ia32_struct), + NULL, buf); + goto out; + }
if (use_xsave()) { struct _fpx_sw_bytes fx_sw_user; @@ -396,7 +400,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) */ ret = __copy_from_user(&env, buf, sizeof(env)); if (ret) - goto err_out; + goto out; envp = &env; }
@@ -426,7 +430,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx); if (ret) - goto err_out; + goto out;
sanitize_restored_user_xstate(&fpu->state, envp, user_xfeatures, fx_only); @@ -446,7 +450,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) ret = __copy_from_user(&fpu->state.fxsave, buf_fx, state_size); if (ret) { ret = -EFAULT; - goto err_out; + goto out; }
sanitize_restored_user_xstate(&fpu->state, envp, user_xfeatures, @@ -464,7 +468,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) } else { ret = __copy_from_user(&fpu->state.fsave, buf_fx, state_size); if (ret) - goto err_out; + goto out;
fpregs_lock(); ret = copy_kernel_to_fregs_err(&fpu->state.fsave); @@ -475,7 +479,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) fpregs_deactivate(fpu); fpregs_unlock();
-err_out: +out: if (ret) fpu__clear_user_states(fpu); return ret;
On Mon, Jun 21, 2021 at 12:52:12PM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Ok, how's this below?
It should at least capture the gist of what this commit is trying to achieve as the FPU mess has changed substantially since 4.4 so I'm really cautious here not to break any existing setups.
I've boot-tested this in a VM but Greg, I'd appreciate running it through some sort of stable testing framework if you're using one.
Thx.
--- From: Thomas Gleixner tglx@linutronix.de Date: Wed, 9 Jun 2021 21:18:00 +0200 Subject: [PATCH] x86/fpu: Reset state for all signal restore failures
Commit efa165504943f2128d50f63de0c02faf6dcceb0d upstream.
If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the function just returns but does not clear the FPU state as it does for all other fatal failures.
Clear the FPU state for these failures as well.
Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels") Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Borislav Petkov bp@suse.de Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de --- arch/x86/kernel/fpu/signal.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index 8fc842dae3b3..9a1489b92782 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -262,15 +262,23 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size) return 0; }
- if (!access_ok(VERIFY_READ, buf, size)) + if (!access_ok(VERIFY_READ, buf, size)) { + fpu__clear(fpu); return -EACCES; + }
fpu__activate_curr(fpu);
- if (!static_cpu_has(X86_FEATURE_FPU)) - return fpregs_soft_set(current, NULL, - 0, sizeof(struct user_i387_ia32_struct), - NULL, buf) != 0; + if (!static_cpu_has(X86_FEATURE_FPU)) { + int ret = fpregs_soft_set(current, NULL, 0, + sizeof(struct user_i387_ia32_struct), + NULL, buf); + + if (ret) + fpu__clear(fpu); + + return ret != 0; + }
if (use_xsave()) { struct _fpx_sw_bytes fx_sw_user;
On Mon, Jun 21, 2021 at 07:45:02PM +0200, Borislav Petkov wrote:
On Mon, Jun 21, 2021 at 12:52:12PM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Ok, how's this below?
It should at least capture the gist of what this commit is trying to achieve as the FPU mess has changed substantially since 4.4 so I'm really cautious here not to break any existing setups.
I've boot-tested this in a VM but Greg, I'd appreciate running it through some sort of stable testing framework if you're using one.
This applied to 4.4.y and 4.9.y, but we still need a 4.14.y and 4.19.y version if at all possible.
thanks,
greg k-h
On Tue, Jun 22 2021 at 12:17, Greg KH wrote:
On Mon, Jun 21, 2021 at 07:45:02PM +0200, Borislav Petkov wrote:
On Mon, Jun 21, 2021 at 12:52:12PM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Ok, how's this below?
It should at least capture the gist of what this commit is trying to achieve as the FPU mess has changed substantially since 4.4 so I'm really cautious here not to break any existing setups.
I've boot-tested this in a VM but Greg, I'd appreciate running it through some sort of stable testing framework if you're using one.
This applied to 4.4.y and 4.9.y, but we still need a 4.14.y and 4.19.y version if at all possible.
Everything is possible :)
--- Subject: x86/fpu: Reset state for all signal restore failures From: Thomas Gleixner tglx@linutronix.de Date: Wed Jun 9 21:18:00 2021 +0200
From: Thomas Gleixner tglx@linutronix.de
commit efa165504943f2128d50f63de0c02faf6dcceb0d upstream
If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the function just returns but does not clear the FPU state as it does for all other fatal failures.
Clear the FPU state for these failures as well.
Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels") Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Borislav Petkov bp@suse.de Signed-off-by: Thomas Gleixner tglx@linutronix.de Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de
--- arch/x86/kernel/fpu/signal.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) --- --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -281,15 +281,21 @@ static int __fpu__restore_sig(void __use return 0; }
- if (!access_ok(VERIFY_READ, buf, size)) - return -EACCES; + if (!access_ok(VERIFY_READ, buf, size)) { + ret = -EACCES; + goto out_err; + }
fpu__initialize(fpu);
- if (!static_cpu_has(X86_FEATURE_FPU)) - return fpregs_soft_set(current, NULL, - 0, sizeof(struct user_i387_ia32_struct), - NULL, buf) != 0; + if (!static_cpu_has(X86_FEATURE_FPU)) { + ret = fpregs_soft_set(current, NULL, + 0, sizeof(struct user_i387_ia32_struct), + NULL, buf) != 0; + if (ret) + goto out_err; + return 0; + }
if (use_xsave()) { struct _fpx_sw_bytes fx_sw_user; @@ -349,6 +355,7 @@ static int __fpu__restore_sig(void __use fpu__restore(fpu); local_bh_enable();
+ /* Failure is already handled */ return err; } else { /* @@ -356,13 +363,14 @@ static int __fpu__restore_sig(void __use * state to the registers directly (with exceptions handled). */ user_fpu_begin(); - if (copy_user_to_fpregs_zeroing(buf_fx, xfeatures, fx_only)) { - fpu__clear(fpu); - return -1; - } + if (!copy_user_to_fpregs_zeroing(buf_fx, xfeatures, fx_only)) + return 0; + ret = -1; }
- return 0; +out_err: + fpu__clear(fpu); + return ret; }
static inline int xstate_sigframe_size(void)
On Tue, Jun 22, 2021 at 10:03:03PM +0200, Thomas Gleixner wrote:
On Tue, Jun 22 2021 at 12:17, Greg KH wrote:
On Mon, Jun 21, 2021 at 07:45:02PM +0200, Borislav Petkov wrote:
On Mon, Jun 21, 2021 at 12:52:12PM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Ok, how's this below?
It should at least capture the gist of what this commit is trying to achieve as the FPU mess has changed substantially since 4.4 so I'm really cautious here not to break any existing setups.
I've boot-tested this in a VM but Greg, I'd appreciate running it through some sort of stable testing framework if you're using one.
This applied to 4.4.y and 4.9.y, but we still need a 4.14.y and 4.19.y version if at all possible.
Everything is possible :)
Thanks for this, now queued up!
greg k-h
On Tue, Jun 22, 2021 at 10:03:03PM +0200, Thomas Gleixner wrote:
On Tue, Jun 22 2021 at 12:17, Greg KH wrote:
On Mon, Jun 21, 2021 at 07:45:02PM +0200, Borislav Petkov wrote:
On Mon, Jun 21, 2021 at 12:52:12PM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Ok, how's this below?
It should at least capture the gist of what this commit is trying to achieve as the FPU mess has changed substantially since 4.4 so I'm really cautious here not to break any existing setups.
I've boot-tested this in a VM but Greg, I'd appreciate running it through some sort of stable testing framework if you're using one.
This applied to 4.4.y and 4.9.y, but we still need a 4.14.y and 4.19.y version if at all possible.
Everything is possible :)
Subject: x86/fpu: Reset state for all signal restore failures From: Thomas Gleixner tglx@linutronix.de Date: Wed Jun 9 21:18:00 2021 +0200
From: Thomas Gleixner tglx@linutronix.de
commit efa165504943f2128d50f63de0c02faf6dcceb0d upstream
If access_ok() or fpregs_soft_set() fails in __fpu__restore_sig() then the function just returns but does not clear the FPU state as it does for all other fatal failures.
Clear the FPU state for these failures as well.
Fixes: 72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels") Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Borislav Petkov bp@suse.de Signed-off-by: Thomas Gleixner tglx@linutronix.de Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87mtryyhhz.ffs@nanos.tec.linutronix.de
arch/x86/kernel/fpu/signal.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-)
--- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -281,15 +281,21 @@ static int __fpu__restore_sig(void __use return 0; }
- if (!access_ok(VERIFY_READ, buf, size))
return -EACCES;
- if (!access_ok(VERIFY_READ, buf, size)) {
ret = -EACCES;
goto out_err;
- }
fpu__initialize(fpu);
- if (!static_cpu_has(X86_FEATURE_FPU))
return fpregs_soft_set(current, NULL,
0, sizeof(struct user_i387_ia32_struct),
NULL, buf) != 0;
- if (!static_cpu_has(X86_FEATURE_FPU)) {
ret = fpregs_soft_set(current, NULL,
0, sizeof(struct user_i387_ia32_struct),
NULL, buf) != 0;
if (ret)
goto out_err;
return 0;
- }
if (use_xsave()) { struct _fpx_sw_bytes fx_sw_user; @@ -349,6 +355,7 @@ static int __fpu__restore_sig(void __use fpu__restore(fpu); local_bh_enable();
return err; } else { /*/* Failure is already handled */
@@ -356,13 +363,14 @@ static int __fpu__restore_sig(void __use * state to the registers directly (with exceptions handled). */ user_fpu_begin();
if (copy_user_to_fpregs_zeroing(buf_fx, xfeatures, fx_only)) {
fpu__clear(fpu);
return -1;
}
if (!copy_user_to_fpregs_zeroing(buf_fx, xfeatures, fx_only))
return 0;
}ret = -1;
- return 0;
+out_err:
- fpu__clear(fpu);
- return ret;
} static inline int xstate_sigframe_size(void)
Hm, did you build this?
I get the following build error: arch/x86/kernel/fpu/signal.c: In function ‘__fpu__restore_sig’: arch/x86/kernel/fpu/signal.c:285:17: error: ‘ret’ undeclared (first use in this function); did you mean ‘net’? 285 | ret = -EACCES; | ^~~ | net arch/x86/kernel/fpu/signal.c:285:17: note: each undeclared identifier is reported only once for each function it appears in arch/x86/kernel/fpu/signal.c:374:1: warning: control reaches end of non-void function [-Wreturn-type] 374 | } | ^
I'll fix it up, it's an "obvious" change :)
thanks,
greg k-h
On Wed, Jun 23 2021 at 17:04, Greg KH wrote:
On Tue, Jun 22, 2021 at 10:03:03PM +0200, Thomas Gleixner wrote: I get the following build error: arch/x86/kernel/fpu/signal.c: In function ‘__fpu__restore_sig’: arch/x86/kernel/fpu/signal.c:285:17: error: ‘ret’ undeclared (first use in this function); did you mean ‘net’? 285 | ret = -EACCES; | ^~~ | net arch/x86/kernel/fpu/signal.c:285:17: note: each undeclared identifier is reported only once for each function it appears in arch/x86/kernel/fpu/signal.c:374:1: warning: control reaches end of non-void function [-Wreturn-type] 374 | } | ^
I'll fix it up, it's an "obvious" change :)
Duh. /me blushes
linux-stable-mirror@lists.linaro.org