Linux Kernel
CVE-2026-23102
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain local low-privileged code execution
-
DeliveryCraft malformed SVE signal context (SVE_SIG_FLAG_SM)
-
ExploitInvoke sigreturn to restore state
-
ExecutionKernel reads out-of-bounds sve_state memory
-
ImpactTask killed via SIGKILL or fatal fault
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires arm64 hardware with SME (Scalable Matrix Extension) support running a Linux 6.19 release-candidate kernel (rc1-rc6). Exploitation is not possible from a normal signal flow because, as the description notes, a legitimate SVE signal context with SVE_SIG_FLAG_SM normally implies TIF_SME is already set. The inconsistent state arises only in unusual-but-legitimate cases: (a) userspace has modified the SVE signal context, (b) the context was saved in another task's context and restored (e.g. via CRIU), or (c) ptrace was used to set SVCR.SM after sigreturn entry (which otherwise clears it). Limiting factors: attacker must already have local execution as the affected task (PR:L), must operate on arm64+SME hardware, and only pre-release RC kernels are affected - stable production kernels are not listed. The realized impact is a fatal fault or SIGKILL of the task (availability); loaded secret data is never exposed to EL0 and cannot be exfiltrated. |
| Impact | Signals point to a real but low-priority issue despite the 7.1 HIGH base score. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H) establishes this as a LOCAL vulnerability requiring an already-authenticated low-privileged context, not a remotely reachable flaw. EPSS is 0.03% (7th percentile), among the lowest tier, and there is no CISA KEV listing and no public exploit identified, so there is no evidence of exploitation interest. The vuln.today decision label is 'this_week', indicating routine patch cadence rather than emergency. A notable conflict: NVD scores confidentiality as C:H, but the description explicitly states that although out-of-bounds data may be loaded into streaming SVE registers, 'these values are never exposed' at EL0 and cannot be saved back to memory via ptrace/signals - so the realized impact is primarily availability (the task may be killed by SIGKILL or the kernel may take a fatal fault), making the C:H rating questionable and the practical risk closer to a local denial-of-service. Compounding the low urgency, only Linux 6.19 release-candidate kernels (rc1-rc6) are listed as affected, and the bug requires arm64 hardware with SME support. Net: treat as a standard local hardening fix, not an actively exploited priority. |
| Exploit ScenarioDerived | A local low-privileged user on an arm64 system with SME support crafts or modifies an SVE signal context (setting SVE_SIG_FLAG_SM), or restores a context saved from another task via CRIU, then invokes sigreturn; the kernel enters an inconsistent state (SVCR.SM set while TIF_SME clear) and performs an out-of-bounds read of sve_state, which can trigger a fatal fault or cause the task to be killed with SIGKILL. No public exploit identified at time of analysis; the scenario is self-inflicted denial-of-service for the triggering task rather than cross-user compromise, and because the vector is local with low complexity it is easy to reproduce by a user who can run code on the host. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Nov 05, 2026
Restoring an SVE signal context on arm64 kernels built with SME support can leave a task in an inconsistent FP/SIMD state that causes out-of-bounds kernel memory reads and eventual forced termination of the task. Only Linux 6.19 release candidates (rc1 through rc6) are listed as affected, and the trigger requires local execution as the task being restored plus unusual-but-legitimate conditions - a user-modified SVE signal context, a context saved under a different task (e.g. CRIU), or ptrace setting SVCR.SM after sigreturn entry. The assessed impact is availability only: the task may take a fatal fault or be killed with SIGKILL, while any data pulled into streaming SVE registers is trapped from EL0 and never returned to userspace; EPSS is 0.03%, there is no KEV listing, and no public exploit has been identified at time of analysis.
Earlier versions of this analysis (1)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Fix restoration of SVE context
When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.
RemediationAI
There is no vendor-assigned fix version in the supplied data; the fix is delivered as upstream kernel commits listed at https://git.kernel.org/stable/c/7b5a52cf252a0d2e89787b645290ad288878f332, https://git.kernel.org/stable/c/9bc3adba8c35119be80ab20217027720446742f2, https://git.kernel.org/stable/c/ce820dd4e6e2d711242dc4331713b9bb4fe06d09 and https://git.kernel.org/stable/c/d2907cbe9ea0a54cbe078076f9d089240ee1e2d9, and as distribution updates such as Ubuntu USN-8278-1 (https://ubuntu.com/security/notices/USN-8278-1); confirm the exact patched kernel build for your branch against that advisory before upgrading, since the input confirms patch availability but not the released version numbers. Because the affected population is limited to 6.19-rc1 through rc6 on SME-capable arm64 hardware, the most direct containment for pre-production systems is to move off the release candidate onto the fixed build or a stable GA kernel rather than running the RC while hunting for a backport - note that this changes the kernel ABI level of the test platform. Where patching must be staged, reduce exposure to the documented trigger paths: if CRIU or another checkpoint/restore tool is not needed, disable its use for tasks carrying SVE/SME state, since a context saved in one task and restored in another is a stated precondition; likewise restrict ptrace of SVE-using processes (e.g. Yama ptrace_scope or removing CAP_SYS_PTRACE from untrusted containers), accepting that this breaks debuggers and profilers on those workloads. These only close specific trigger paths - a user-modified signal context remains a route - so they are stopgaps pending the upstream fix, not substitutes for it.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in the arm64 FPSIMD/SVE/SME signal-restore path. When SME is present, the kernel tracks streaming-mode use through SVCR.SM plus the TIF_SME and TIF_SVE thread flags and the fp_type field, and sizes hardware access via SMCR_ELx.LEN. If a restored SVE signal context carries SVE_SIG_FLAG_SM while TIF_SME is clear, task_fpsimd_load() skips reconfiguring SMCR_ELx, leaving an arbitrary hardware value in place, and then calls sve_load_state() to read streaming-mode SVE registers using that stale LEN. Because SMCR_ELx.LEN can exceed the task's own streaming vector length, the kernel reads past the end of the allocated sve_state buffer - a CWE-125 out-of-bounds read. The description is explicit that no confidentiality impact materializes: fpsimd_bind_task_to_cpu() sets CPACR_ELx.SMEN to trap EL0 access to streaming SVE registers, and fpsimd_save_user_state() validates the live vector length before writing state back, so the out-of-bounds data is neither reachable from userspace nor savable into memory for later observation via ptrace or signals. The observable consequence is instead a fatal fault or a SIGKILL issued by fpsimd_save_user_state() when the live length mismatches. A second, distinct defect is that restoring a context with SVE_SIG_FLAG_SM clear does not clear SVCR.SM, so a task left in streaming mode has register state merged inconsistently (SVE data loaded at the non-streaming length, FPSIMD merged at the streaming length), though that state is still legitimate from the kernel's point of view. The trigger conditions are unusual-by-design rather than a normal signal flow: the description notes a genuine SVE_SIG_FLAG_SM context normally implies TIF_SME is already set, and syscall entry clears SVCR.SM, so the bad states come from userspace-modified contexts, cross-task restores such as CRIU, or ptrace writes after sigreturn entry. Remediation in the upstream fix sets TIF_SME whenever SVCR.SM is set (allocating sme_state without zeroing it so live ZA state is preserved), clears SVCR.SM when SVE_SIG_FLAG_SM is clear, and moves the SVCR/TIF_SVE/TIF_SME/fp_type manipulation earlier - right after sve_state/sme_state allocation - so the flags stay consistent even if a fault occurs while reading the register payload.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Local triggering via sigreturn/ptrace/CRIU gives AV:L/PR:L; the description states loaded secrets are never exposed so C:N, with the real impact being task SIGKILL/kernel fault, hence A:H.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Fix restoration of SVE context
When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.
(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.
This can only occur in unusual (but legitimate) cases where the SVE signal context has either been modified by userspace or was saved in the context of another task (e.g. as with CRIU), as otherwise the presence of an SVE signal context with SVE_SIG_FLAG_SM implies that TIF_SME is already set.
While in this state, task_fpsimd_load() will NOT configure SMCR_ELx (leaving some arbitrary value configured in hardware) before restoring SVCR and attempting to restore the streaming mode SVE registers from memory via sve_load_state(). As the value of SMCR_ELx.LEN may be larger than the task's streaming SVE vector length, this may read memory outside of the task's allocated sve_state, reading unrelated data and/or triggering a fault.
While this can result in secrets being loaded into streaming SVE registers, these values are never exposed. As TIF_SME is clear, fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0 accesses to streaming mode SVE registers, so these cannot be accessed directly at EL0. As fpsimd_save_user_state() verifies the live vector length before saving (S)SVE state to memory, no secret values can be saved back to memory (and hence cannot be observed via ptrace, signals, etc).
When the live vector length doesn't match the expected vector length for the task, fpsimd_save_user_state() will send a fatal SIGKILL signal to the task. Hence the task may be killed after executing userspace for some period of time.
(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.
This can only occur in unusual (but legitimate) cases where ptrace has been used to set SVCR.SM after entry to the sigreturn syscall, as syscall entry clears SVCR.SM.
In these cases, the the provided SVE register data will be loaded into the task's sve_state using the non-streaming SVE vector length and the FPSIMD registers will be merged into this using the streaming SVE vector length.
Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.
For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.
Executive ViewAI
CVE-2026-23102 is a high-severity vulnerability in Linux kernel release candidates (6.19-rc1 through 6.19-rc6) built with Scalable Matrix Extension (SME) support on arm64 systems, affecting only development or pre-production environments. A local attacker could trigger a kernel memory read and task termination, but exploitation requires specific unusual conditions, and the impact is limited to availability with no data exposure to userspace. Leadership should care because unpatched pre-release kernels in testing pipelines could cause service interruptions, though no production systems are affected.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
GitHub PoC
Exploit-DB