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.
Published: 2026-02-14
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel warning with no functional impact
Action: Patch Now
AI Analysis

Impact

In the ARM64 Linux kernel, a defect in the ptrace handling for the NT_ARM_SVE register set can leave a task’s TIF_SVE flag unset when SVE is supported but SME is not. This omission causes the kernel to log a benign warning during a later state restore, but it does not alter process execution, confidentiality, or integrity. The bug was introduced during a refactor that moved the TIF_SVE assignment inside a SME‑only code block.

Affected Systems

The vulnerability is confined to ARM64 kernels that compile with CONFIG_ARM64_SVE enabled while CONFIG_ARM64_SME is disabled. It appears in the 6.19 release candidate series (rc1 through rc6) and any downstream kernels that incorporate those revisions. Only processes that have ptrace access to the NT_ARM_SVE register set are affected.

Risk and Exploitability

The CVSS score of 5.5 and an EPSS below 1 % indicate a moderate severity and very low likelihood of exploitation as of the latest data. The issue is not present in the CISA KEV catalog. An attacker would need the ability to perform ptrace on a target process, typically local privileged access or the same user running two processes. Since the only observable effect is a kernel warning, the risk to confidentiality, integrity, or availability is negligible.

Generated by OpenCVE AI on April 18, 2026 at 19:41 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the kernel to a version that includes the upstream patch that removes the incorrect SME guard and restores the TIF_SVE flag on SVE registers
  • If an immediate upgrade is impossible, limit ptrace capabilities by configuring a restrictive SELinux or AppArmor policy, or by running potentially vulnerable processes as non‑privileged users that cannot request ptrace
  • For hosts that do not rely on SVE, rebuild the kernel with CONFIG_ARM64_SVE disabled to eliminate the code path entirely

Generated by OpenCVE AI on April 18, 2026 at 19:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 18 Mar 2026 13:45:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.19:rc6:*:*:*:*:*:*

Mon, 16 Feb 2026 12:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low

Sat, 14 Feb 2026 15:15:00 +0000

Type Values Removed Values Added
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.
Title arm64/fpsimd: ptrace: Fix SVE writes on !SME systems
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-02-14T15:09:47.048Z

Reserved: 2026-01-13T15:37:45.968Z

Link: CVE-2026-23114

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-02-14T15:16:06.500

Modified: 2026-03-18T13:41:42.553

Link: CVE-2026-23114

cve-icon Redhat

Severity : Low

Publid Date: 2026-02-14T00:00:00Z

Links: CVE-2026-23114 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-18T19:45:08Z

Weaknesses