CVE-2025-38169

What it actually does

On ARM64 systems with SME enabled, fpsimd_thread_switch() restores kernel FPSIMD state while the CPU remains in streaming SVE mode; the subsequent fpsimd_flush_cpu_state() issues SMSTOP, which resets FPSIMD/SVE/SME registers and clobbers the just-restored kernel state.

Why it matters to the business

Systems running affected Linux kernels on SME-capable ARM64 hardware may experience kernel-level floating-point state corruption, leading to application crashes, incorrect scientific or cryptographic results, or kernel instability that requires reboots or patches.

How an attack unfolds

An attacker with local code execution on an SME-enabled ARM64 system triggers repeated context switches immediately after kernel FPSIMD state restoration; the resulting register clobbering can be abused to corrupt in-kernel data structures and potentially escalate privileges or cause denial of service.

How to fix it

Update the Linux kernel to a version containing commit 55d52af498daea75aa03ba9b7e444c8ae495ac20; for sofia-sip on Mageia 8 apply package 1.12.11-10.1.mga8. Reboot after installation.

How to confirm the fix worked

Verify the running kernel contains commit 55d52af498daea75aa03ba9b7e444c8ae495ac20 or later equivalent; on SME hardware confirm no FPSIMD corruption occurs during context switches after the update.

Typical attack path

1. Obtain local execution on SME-capable ARM64 Linux system
2. Schedule threads to force fpsimd_thread_switch() while CPU is in streaming SVE mode
3. Trigger fpsimd_load_kernel_state() followed by SMSTOP-induced register reset
4. Leverage resulting kernel FPSIMD corruption for further exploitation

How to detect it

Review kernel logs for FPSIMD or SVE register corruption messages around context-switch events; examine crash dumps showing unexpected SMSTOP or streaming-mode exits on SME hardware.

What your security team should do

• Prioritize kernel updates on all ARM64 systems with SME support
• Apply the fixed commit or equivalent stable release immediately
• Test workloads that rely on kernel FPSIMD state after patching
• Monitor EPSS trend and any new exploit reports given the 481-day disclosure window