Cloudanix VulnDB

CVE-2025-38170

None

CVSS

—

EPSS

0.2%

Published

Jul 3, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in the Linux kernel on certain processors can let attackers trick the system into using old saved data, potentially allowing them to gain elevated access.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in arm64 SME trap handling allows a task to retain TIF_SME set with TIF_FOREIGN_FPSTATE clear while live CPU state is stale, enabling reuse of outdated FPSIMD/SVE/SME context across preemptions.

Why it matters to the business

Arm64 Linux systems may experience kernel warnings, instability, or successful privilege escalation in high-preemption or SME-enabled workloads; widespread kernel deployments increase exposure urgency.

How an attack unfolds

Attacker triggers SME traps on one CPU, forces preemption and migration before/after state manipulation, then returns to the original CPU where stale hardware state is incorrectly reused without reload, bypassing expected foreign state handling.

How to fix it

Update the Linux kernel to commit de89368de3894a8db27caeb8fd902ba1c49f696a or later; rebuild and reboot affected systems; apply equivalent fixes for downstream distributions such as Mageia packages when available.

How to confirm the fix worked

Confirm kernel version contains the referenced commit; run SME-enabled workloads under heavy preemption and verify absence of do_sme_acc warnings; inspect fpsimd context switch paths for fpsimd_flush_task_state calls.

Typical attack path

  1. Trigger SME access trap on initial CPU with TIF_SME clear
  2. Force preemption and CPU migration setting TIF_FOREIGN_FPSTATE
  3. Execute trap handler that sets TIF_SME without clearing stale state
  4. Preempt again and migrate back to original CPU
  5. Reuse stale per-CPU state on return to userspace without reload

How to detect it

Search kernel logs for do_sme_acc WARN_ON messages; correlate with process migrations and TIF_SME flag changes in scheduler traces; examine ftrace or perf data around fpsimd context switches for missing flush operations.

  • WARN_ON(1) in do_sme_acc
  • TIF_SME set with TIF_FOREIGN_FPSTATE clear
  • fpsimd_last_state reuse without fpsimd_flush_task_state

What your security team should do

  • Prioritize kernel upgrades on all arm64 production systems within the next patch cycle
  • Enable kernel panic on oops or warning to surface exploitation attempts
  • Monitor for increased context-switch overhead after applying the fix
  • Review downstream package updates for Mageia and similar distributions

The record

In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: Discard stale CPU state when handling SME traps The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set: | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); This is very similar to the SVE issue we fixed in commit: 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps") The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g. | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SME clear, SME 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(); | | /* With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | 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 SME 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. Note: this was originallly posted as [1]. [ Rutland: rewrite commit message ]

Affected packages

Ecosystem Package Introduced Fixed
Debian:12 linux 0 No fix
Debian:13 linux 0 No fix
Debian:14 linux 0 6.12.35-1
Linux Kernel 5.19.0 6.1.142
Mageia:9 kernel 0 6.6.101-1.mga9
Mageia:9 kernel-linus 0 6.6.101-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.10-7.mga9
Mageia:9 kmod-xtables-addons 0 3.24-83.mga9
Mageia:9 wireless-regdb 0 20250710-1.mga9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.6.1.160000.2.4
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.6.1

Related vulnerabilities