cbcvebase.
CVE-2026-23114
published 2026-02-14

CVE-2026-23114: In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: ptrace: Fix SVE writes on !SME systems When SVE is supported but SME is not…

PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.10%
1.0th percentile
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: ptrace: Fix SVE writes on !SME systems When SVE is supported but SME is not supported, a ptrace write to the NT_ARM_SVE regset can place the tracee into an invalid state where (non-streaming) SVE register data is stored in FP_STATE_SVE format but TIF_SVE is clear. This can result in a later warning from fpsimd_restore_current_state(), e.g. WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748 When this happens, fpsimd_restore_current_state() will set TIF_SVE, placing the task into the correct state. This occurs before any other check of TIF_SVE can possibly occur, as other checks of TIF_SVE only happen while the FPSIMD/SVE/SME state is live. Thus, aside from the warning, there is no functional issue. This bug was introduced during rework to error handling in commit: 9f8bf718f2923 ("arm64/fpsimd: ptrace: Gracefully handle errors") ... where the setting of TIF_SVE was moved into a block which is only executed when system_supports_sme() is true. Fix this by removing the system_supports_sme() check. This ensures that TIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of unconditionally manipulating the tracee's saved svcr value. The manipulation of svcr is benign and inexpensive, and we already do similar elsewhere (e.g. during signal handling), so I don't think it's worth guarding this with system_supports_sme() checks. Aside from the above, there is no functional change. The 'type' argument to sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when system_supports_sme(), so the ARM64_VEC_SME case in the switch statement is still unreachable when !system_supports_sme(). When CONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(), and the compiler can constant-fold for the case where type is ARM64_VEC_SVE, removing the logic for other cases.

Affected

13 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.18.8-1 (forky)linux 6.18.8-1 (forky)
linuxlinux
linuxlinux>= 9f8bf718f29230e38a048d08fc3063e316cd60c1 < 4f39984176e7edcaba3432b6c649c6fe93bf2f804f39984176e7edcaba3432b6c649c6fe93bf2f80
linuxlinux>= 9f8bf718f29230e38a048d08fc3063e316cd60c1 < 128a7494a9f15aad60cc6b7e3546bf481ac54a13128a7494a9f15aad60cc6b7e3546bf481ac54a13
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.18.8-16.18.8-1
linuxlinux_kernel>= 6.16 < 6.18.86.18.8
ubuntulinux-azure-6.17
ubuntulinux-azure-fde-6.17
ubuntulinux-gcp-6.17
ubuntulinux-oem-6.17
ubuntulinux-oracle-6.17
ubuntulinux-realtime-6.17

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
ghsa7.8HIGH
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.