Linux: Out-of-bounds Read
CVE-2026-23102 is a high-severity out-of-bounds read vulnerability in Linux, with a CVSS 3.1 base score of 7.1 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 9bc3adba8c35119be80ab20217027720446742f2, ce820dd4e6e2d711242dc4331713b9bb4fe06d09, 7b5a52cf252a0d2e89787b645290ad288878f332 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.14% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 9bc3adba8c35119be80ab20217027720446742f2 or ce820dd4e6e2d711242dc4331713b9bb4fe06d09 or 7b5a52cf252a0d2e89787b645290ad288878f332 or d2907cbe9ea0a54cbe078076f9d089240ee1e2d9, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.1.162 or 6.6.123 or 6.18.8, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 85ed24dad2904f7c141911d91b7807ab02694b5e up to, but not including, 9bc3adba8c35119be80ab20217027720446742f2; 85ed24dad2904f7c141911d91b7807ab02694b5e up to, but not including, ce820dd4e6e2d711242dc4331713b9bb4fe06d09; 85ed24dad2904f7c141911d91b7807ab02694b5e up to, but not including, 7b5a52cf252a0d2e89787b645290ad288878f332; 85ed24dad2904f7c141911d91b7807ab02694b5e up to, but not including, d2907cbe9ea0a54cbe078076f9d089240ee1e2d9; 5.19 | 9bc3adba8c35119be80ab20217027720446742f2, ce820dd4e6e2d711242dc4331713b9bb4fe06d09, 7b5a52cf252a0d2e89787b645290ad288878f332, d2907cbe9ea0a54cbe078076f9d089240ee1e2d9 |
| Linux | Linux Kernel | 5.19 up to, but not including, 6.1.162; 6.2 up to, but not including, 6.6.123; 6.7 up to, but not including, 6.18.8; 6.19 | 6.1.162, 6.6.123, 6.18.8 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- NoneNothing can be modified.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H. Scored by NVD.
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Out-of-bounds Read
The product reads data past the end, or before the beginning, of the intended buffer.
How developers prevent this class of flaw
- Use a language that provides appropriate memory abstractions.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
Recent Out-of-bounds Read vulnerabilities
- 7.8 High severity
- 9.1 Critical severity
- 7.1 High severity
- 7.1 High severity
- 7.5 High severity
- 7.5 High severity
Spotted an error? Tell us.