CVE-2026-23114

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