CVE-2024-50275

In the Linux kernel, the following vulnerability has been resolved:

arm64/sve: Discard stale CPU state when handling SVE traps

The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIFSVE set and TIFFOREIGNFPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from dosveacc() where SVE traps are not expected while TIFSVE is set:

| if (testandsetthreadflag(TIFSVE)) | WARNON(1); /* SVE access shouldn't have trapped */

Warnings of this form have been reported intermittently, e.g.

https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/

The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g.

| void dosveacc(unsigned long esr, struct ptregs *regs) | { | // Trap on CPU 0 with TIFSVE clear, SVE traps enabled | // task->fpsimdcpu is 0. | // percpuptr(&fpsimdlaststate, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIFFOREIGNFPSTATE is set. | | getcpufpsimdcontext(); | | if (testandsetthreadflag(TIFSVE)) | WARNON(1); /* SVE access shouldn't have trapped */ | | sveinitregs() { | if (!testthreadflag(TIFFOREIGNFPSTATE)) { | ... | } else { | fpsimdtosve(current); | current->thread.fptype = FPSTATESVE; | } | } | | putcpufpsimdcontext(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimdcpu is still 0 | // If percpuptr(&fpsimdlaststate, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIFFOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }

Fix the case where the state is not live and TIFFOREIGNFPSTATE is set by calling fpsimdflushtaskstate() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIFFOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.