CVE-2026-23114
Unknown Unknown - Not Provided
Ptrace Write Handling Flaw in Linux arm64 FPSIMD Causes State Warning

Publication date: 2026-02-14

Last updated on: 2026-03-18

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-14
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-02-14
EPSS Evaluated
2026-05-05
NVD
CVE-2026-23114
EUVD
EUVD-2026-6033
Affected Vendors & Products
Showing 7 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.16 (inc) to 6.18.8 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's arm64/fpsimd subsystem related to ptrace operations on systems that support SVE (Scalable Vector Extension) but do not support SME (Scalable Matrix Extension). A ptrace write to the NT_ARM_SVE register set can put the traced process (tracee) into an invalid state where SVE register data is stored incorrectly without the corresponding state flag (TIF_SVE) being set.

This mismatch causes a warning during the restoration of the FPSIMD state, but the kernel code then sets the TIF_SVE flag to correct the state before any other checks occur, preventing functional issues. The root cause was a code change that incorrectly limited setting the TIF_SVE flag only to systems supporting SME, which was fixed by removing that restriction.


How can this vulnerability impact me? :

The impact of this vulnerability is minimal in practical terms. Although the ptrace write can place the tracee into an invalid state and trigger a kernel warning, the kernel corrects this state automatically by setting the appropriate flag (TIF_SVE).

Aside from the warning message, there is no functional issue or security impact reported. The fix ensures the system behaves correctly without causing crashes or incorrect behavior.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can manifest as a warning message in the system logs when the fpsimd_restore_current_state() function detects an invalid state caused by ptrace writes to the NT_ARM_SVE regset on systems where SVE is supported but SME is not.

Specifically, you may observe a warning similar to the following in your kernel logs or dmesg output:

  • WARNING: CPU: <cpu_id> PID: <pid> at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748

To detect this, you can check your kernel logs using commands such as:

  • dmesg | grep fpsimd_restore_current_state
  • journalctl -k | grep fpsimd_restore_current_state

Additionally, monitoring for ptrace operations on NT_ARM_SVE regset may require custom tracing or debugging tools, but the primary indicator is the warning message in kernel logs.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability has been fixed by removing the system_supports_sme() check to ensure that TIF_SVE is set correctly for SVE-formatted writes to NT_ARM_SVE.

Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix for this vulnerability.
  • Monitor kernel logs for the warning message indicating the issue to identify if your system is affected.
  • Avoid using ptrace writes to the NT_ARM_SVE regset on systems where SVE is supported but SME is not, if possible, until the fix is applied.

Since the issue mainly causes a warning and no functional problem beyond that, applying the kernel patch or update is the recommended and effective mitigation.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart