{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-38169", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-38169" ], "published": "2025-07-03T08:36:23Z", "summary": "arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP\n\nOn system with SME, a thread's kernel FPSIMD state may be erroneously\nclobbered during a context switch immediately after that state is\nrestored. Systems without SME are unaffected.\n\nIf the CPU happens to be in streaming SVE mode before a context switch\nto a thread with kernel FPSIMD state, fpsimd_thread_switch() will\nrestore the kernel FPSIMD state using fpsimd_load_kernel_state() while\nthe CPU is still in streaming SVE mode. When fpsimd_thread_switch()\nsubsequently calls fpsimd_flush_cpu_state(), this will execute an\nSMSTOP, causing an exit from streaming SVE mode. The exit from\nstreaming SVE mode will cause the hardware to reset a number of\nFPSIMD/SVE/SME registers, clobbering the FPSIMD state.\n\nFix this by calling fpsimd_flush_cpu_state() before restoring the kernel\nFPSIMD state.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.20-1+rpt1~bpo12+1", "1:6.12.25-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.20-1+rpt1~bpo12+1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" }, "1:6.12.25-1+rpt1": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.12.19-1+rpt1~bpo12+1", "1:6.12.19-1+rpt1", "1:6.12.20-1+rpt1", "1:6.12.25-1+rpt1+trixie" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1~bpo12+1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-2712", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.19+rpt-rpi-v8", "binary_version": "1:6.12.19-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-2712", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.20+rpt-rpi-v8", "binary_version": "1:6.12.20-1+rpt1" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-2712", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8", "binary_version": "1:6.12.25-1+rpt1+trixie" }, { "binary_name": "linux-image-6.12.25+rpt-rpi-v8-rt", "binary_version": "1:6.12.25-1+rpt1+trixie" } ] }, "database_specific": { "per_version": { "1:6.12.19-1+rpt1~bpo12+1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" }, "1:6.12.19-1+rpt1": { "linux_commit": "121c2c384b9c2f4790ffb31b2cd25c7d75c8fda0", "upstream_version": "6.12.19", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" }, "1:6.12.20-1+rpt1": { "linux_commit": "cd231d4775b14f228606c09f219b48308f6ab3aa", "upstream_version": "6.12.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" }, "1:6.12.25-1+rpt1+trixie": { "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16", "upstream_version": "6.12.25", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.34" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-38169" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/55d52af498daea75aa03ba9b7e444c8ae495ac20" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a305821f597ec943849d3e53924adb88c61ed682" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/01098d893fa8a6edb2b56e178b798e3e6b674f02" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - Triggering requires executing SMSTART/streaming-SVE instructions at EL0 on the affected CPU and generating local scheduler pressure, so the attacker must be able to run code on the target. A remote peer cannot place the CPU into streaming SVE mode.\nAC:L - The attacker controls both sides of the race \u2014 they create the streaming-mode task and the kernel-mode NEON workload (AF_ALG, dm-crypt/fscrypt I/O, kTLS), and can pin both to one CPU via sched_setaffinity so ordinary tick preemption reproduces the clobber on demand. No memory layout or victim state outside the attacker's influence is needed, and CONFIG_ARM64_SME is default y.\nPR:L - do_sme_acc() enables SME and streaming mode for any EL0 task with no capability, namespace, or sysctl gate, and driving kernel-mode NEON via AF_ALG or plain I/O on an encrypted/checksummed filesystem needs no privilege. Only unprivileged local code execution is required.\nUI:N - The attacker's own tasks supply both the streaming-mode context and the preempted kernel NEON section; no victim action is needed, and any concurrent crypto/RAID work on the system is silently corrupted.\nS:U - The corruption is confined to kernel FPSIMD register state managed by the same kernel security authority; KVM already flushes and SMSTOPs guest FP state in kvm_arch_vcpu_put_fp(), so no guest/host or IOMMU boundary is crossed.\nC:H - Zeroing V0-V31 mid-operation destroys the in-register AES round-key schedule and IV (aes-ce.S load_round_keys/cbciv) or the ChaCha20 state, so the affected blocks are emitted under a known all-zero key \u2014 a fixed, invertible transform. An attacker who observes the resulting dm-crypt/fscrypt blocks or IPsec/kTLS/WireGuard packets recovers the plaintext that encryption was supposed to protect.\nI:H - Kernel crypto, hash, CRC and RAID6 computations silently return wrong results that are written to disk and the wire, corrupting encrypted volumes, RAID parity, filesystem checksums and dm-verity/dm-integrity data. A zeroed GHASH key also yields predictable authentication tags, enabling forgery against integrity-protected data.\nA:H - The silent miscomputation propagates into dm-verity/dm-integrity/filesystem checksum verification failures, producing I/O errors, forced read-only remounts, errors=panic aborts and Android restart-on-corruption reboots, plus unrecoverable RAID6 parity loss. The attacker can trigger it repeatedly and indefinitely." } } }