On Wed, Apr 26, 2023 at 05:35:08PM -0500, Can Sun wrote: > [ Upstream commit 59f5ede3bc0f00eb856425f636dab0c10feb06d8 ] > > The FPU usage related to task FPU management is either protected by > disabling interrupts (switch_to, return to user) or via fpregs_lock() which > is a wrapper around local_bh_disable(). When kernel code wants to use the > FPU then it has to check whether it is possible by calling irq_fpu_usable(). > > But the condition in irq_fpu_usable() is wrong. It allows FPU to be used > when: > > !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle() > > The latter is checking whether some other context already uses FPU in the > kernel, but if that's not the case then it allows FPU to be used > unconditionally even if the calling context interrupted a fpregs_lock() > critical region. If that happens then the FPU state of the interrupted > context becomes corrupted. > > Allow in kernel FPU usage only when no other context has in kernel FPU > usage and either the calling context is not hard interrupt context or the > hard interrupt did not interrupt a local bottomhalf disabled region. > > It's hard to find a proper Fixes tag as the condition was broken in one way > or the other for a very long time and the eager/lazy FPU changes caused a > lot of churn. Picked something remotely connected from the history. > > This survived undetected for quite some time as FPU usage in interrupt > context is rare, but the recent changes to the random code unearthed it at > least on a kernel which had FPU debugging enabled. There is probably a > higher rate of silent corruption as not all issues can be detected by the > FPU debugging code. This will be addressed in a subsequent change. > > Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave") > Reported-by: Filipe Manana <fdmanana@xxxxxxxx> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Tested-by: Filipe Manana <fdmanana@xxxxxxxx> > Reviewed-by: Borislav Petkov <bp@xxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx > Cc: Can Sun <cansun@xxxxxxxxxx> When you send on a patch that you backported, you need to also sign-off on the change. Please fix that up and resend. thanks, greg k-h