CVE-2024-50275: arm64/sve: Discard stale CPU state when handling SVE traps
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
TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state
is stale (e.g. with SVE traps enabled). This has been observed to result
in warnings from do_sve_acc() where SVE traps are not expected while
TIF_SVE is set:
| if (test_and_set_thread_flag(TIF_SVE))
| WARN_ON(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 do_sve_acc(unsigned long esr, struct pt_regs *regs)
| {
| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled
| // task->fpsimd_cpu is 0.
| // per_cpu_ptr(&fpsimd_last_state, 0) is task.
|
| ...
|
| // Preempted; migrated from CPU 0 to CPU 1.
| // TIF_FOREIGN_FPSTATE is set.
|
| get_cpu_fpsimd_context();
|
| if (test_and_set_thread_flag(TIF_SVE))
| WARN_ON(1); /* SVE access shouldn't have trapped */
|
| sve_init_regs() {
| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {
| ...
| } else {
| fpsimd_to_sve(current);
| current->thread.fp_type = FP_STATE_SVE;
| }
| }
|
| put_cpu_fpsimd_context();
|
| // Preempted; migrated from CPU 1 to CPU 0.
| // task->fpsimd_cpu is still 0
| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:
| // - Stale HW state is reused (with SVE traps enabled)
| // - TIF_FOREIGN_FPSTATE is cleared
| // - A return to userspace skips HW state restore
| }
Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set
by calling fpsimd_flush_task_state() 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 TIF_FOREIGN_FPSTATE, forcing the
new state to be reloaded from memory prior to a return to userspace.
Security readout for executives and security teams
Plain-English summary
A Linux kernel race on Arm64 systems using Scalable Vector Extension (SVE) can reuse stale processor state after task preemption and migration. A local, low-privileged user may be able to affect confidentiality, integrity, or system availability. The supplied record rates it CVSS 7.3 (high).
Executive priority
Prioritize remediation for exposed Arm64 compute environments supporting local untrusted workloads. This is high severity but not evidenced as actively exploited. Schedule prompt kernel updates through normal emergency-change procedures where confidentiality or availability impacts would be material.
Technical view
The SVE trap handler can leave TIF_SVE set and TIF_FOREIGN_FPSTATE clear while live CPU state is stale. Returning to userspace may then skip the required hardware-state restore. The upstream correction calls fpsimd_flush_task_state() when state is not live, ensuring a later context switch reloads state from memory.
Likely exposure
Exposure is limited to affected Linux kernels on Arm64 systems where SVE trap and state handling applies. The CVSS vector requires local access and low privileges, with no user interaction. The supplied version data is ambiguous, so kernel builds should be matched against vendor guidance and the linked stable fixes.
Exploitation context
The bundle reports intermittent kernel warnings demonstrating the race, but provides no evidence of malicious exploitation. CISA KEV status is false. Treat exploitation status as unconfirmed; do not interpret the observed warnings as proof of an attack.
Researcher notes
The reported condition depends on preemption and migration during SVE trap handling, potentially returning to the original CPU and reusing stale FPSIMD/SVE state. The bundle does not identify a CWE, public proof of concept, exploitation campaign, or precise distribution-by-distribution package matrix.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix.
Consult the operating-system vendor's advisory for exact affected and corrected package versions.
Prioritize Arm64 hosts running untrusted or low-privileged local workloads.
Restrict unnecessary local account and workload access until affected kernels are updated.
Validation and detection
Inventory Arm64 hosts and determine whether their processors and workloads use SVE.
Map each running kernel build to vendor advisories and the linked stable commits.
Confirm updated hosts booted into the corrected kernel, not merely installed it.
Review logs for unexpected SVE traps or do_sve_acc warnings; absence does not prove safety.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-50275 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.