CVE-2026-98745

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

On certain ARM processors a kernel bug can cause the whole system to crash when programs receive signals if the hardware supports one advanced math feature but not another.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Improper Input Validation
Remediation: Patch
Effort: Medium
Patch risk: Low

What it actually does

The kernel's restore_sve_fpsimd_context() accepts an SVE signal frame with SVE_SIG_FLAG_SM clear yet a non-empty SVE payload on SME-only systems (system_supports_sme() true, system_supports_sve() false), installing unsupported non-streaming SVE state that later triggers EL1 UNDEF exceptions when the kernel manipulates ZCR_EL1 or FPSIMD/SVE/SME registers.

Why it matters to the business

Systems running on SME-capable ARM64 hardware without SVE support can experience abrupt kernel crashes and panics during normal signal delivery, resulting in application termination, service outages, and potential data loss in workloads that use signals.

How an attack unfolds

An attacker crafts a userspace signal frame containing an SVE payload without the streaming-mode flag, delivers it via a signal to a target process on an affected SME-only system, and causes the kernel to restore invalid state; subsequent FPSIMD operations then trigger an undefined instruction fault and kernel panic.

How to fix it

Apply the upstream fix that updates restore_sve_fpsimd_context() to reject SVE payloads when SVE_SIG_FLAG_SM is clear on SME-only configurations; rebuild and deploy a patched Linux kernel for all affected arm64 systems.

How to confirm the fix worked

Boot the patched kernel on SME-only hardware, replay the original malicious sigcontext test case, and confirm the kernel no longer panics with an undefined-instruction fault; additionally verify that parse_user_sigframe() continues to reject unsupported frames.

Typical attack path

Identify or create a process on an SME-only ARM64 system that receives signals.
Craft a malicious sigcontext with SVE_SIG_FLAG_SM clear and a non-empty SVE payload.
Deliver the signal (e.g., via kill, ptrace, or in-process raise).
Trigger kernel signal restoration path that calls restore_sve_fpsimd_context().
Observe subsequent EL1 UNDEF and kernel panic during FPSIMD state manipulation.

How to detect it

Search kernel logs for Oops - Undefined instruction entries referencing fpsimd_restore_current_state or exit_to_user_mode_loop on arm64 systems; correlate with processes that recently received signals and check dmesg for SME/SVE capability mismatches.

What your security team should do

Prioritize kernel updates for all arm64 systems that advertise SME but not SVE within the next maintenance window.
Monitor vendor advisories for backported patches in distribution kernels.
Add SME/SVE capability checks to pre-deployment hardware validation suites.
Review signal-handling code paths in security-critical applications for robustness against kernel faults.

The record

In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems When system_supports_sme() is true but system_supports_sve() is false, restoring a specifically crafted SVE signal context can result in the task erroneously having non-streaming SVE state. Subsequent attempts to manipulate the task's FPSIMD/SVE/SME state can result in a variety of problems, including fatal EL1 UNDEFs. In such configurations, the kernel always creates an SVE signal context when delivering a signal, and this can only be in one of two states: (1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing streaming mode SVE state. The recorded VL is the task's live streaming VL. (2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The FPSIMD context contains the non-streaming mode FPSIMD state. The recorded VL is 0. Currently restore_sve_fpsimd_context() correctly rejects cases where SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is present. Consequently, restore_sve_fpsimd_context() can place the task in a state where it has non-streaming SVE state even when this is not supported by HW. For example, this can cause a later EL1 UNDEF when the kernel attempts to restore the task's ZCR_EL1 value: | # ./sme-sigcontext-to-sve | Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : fpsimd_restore_current_state+0x258/0x458 | lr : exit_to_user_mode_loop+0xb8/0x188 | sp : ffff80008056be40 | x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040 | x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000 | x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0 | x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300 | x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401 | x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002 | x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001 | x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000 | Call trace: | fpsimd_restore_current_state+0x258/0x458 (P) | exit_to_user_mode_loop+0xb8/0x188 | el0_svc+0x1cc/0x1d0 | el0t_64_sync_handler+0xa0/0xe4 | el0t_64_sync+0x198/0x19c | Code: d5384101 f9400020 53175c03 36b80de0 (d5381202) | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt | Kernel Offset: 0x291fb1000000 from 0xffff800080000000 | PHYS_OFFSET: 0x40000000 | CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f | Memory Limit: none Rework restore_sve_fpsimd_context() to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME are supported, it isn't necessary for restore_sve_fpsimd_context() to handle the case where neither are supported.

Affected packages

Ecosystem	Package	Introduced	Fixed