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 supported, a ptrace write to the NTARMSVE regset can place the tracee into an invalid state where (non-streaming) SVE register data is stored in FPSTATESVE format but TIFSVE is clear. This can result in a later warning from fpsimdrestorecurrentstate(), e.g.

WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimdrestorecurrent_state+0x50c/0x748

When this happens, fpsimdrestorecurrentstate() will set TIFSVE, placing the task into the correct state. This occurs before any other check of TIFSVE can possibly occur, as other checks of TIFSVE 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 TIFSVE was moved into a block which is only executed when systemsupports_sme() is true.

Fix this by removing the systemsupportssme() check. This ensures that TIFSVE is set for (SVE-formatted) writes to NTARMSVE, 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 systemsupports_sme() checks.

Aside from the above, there is no functional change. The 'type' argument to svesetcommon() is only set to ARM64VECSME (in ssveset())) when systemsupportssme(), so the ARM64VECSME case in the switch statement is still unreachable when !systemsupportssme(). When CONFIGARM64SME=n, the only caller of svesetcommon() is sveset(), and the compiler can constant-fold for the case where type is ARM64VECSVE, removing the logic for other cases.