EUVD-2026-55936Severity by source
AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
Local vector confirmed by thread co-residency requirement; AC:H reflects the three concurrent non-default build conditions; PR:L for existing unprivileged thread; C:L and I:L cover disclosure and corruption sub-cases respectively.
Primary rating from Vendor (zephyrproject).
CVSS VectorVendor: zephyrproject
Lifecycle Timeline
2DescriptionCVE.org
On the Zephyr ARM port, enabling the hardware FPU (CONFIG_FPU) forces the "Floating point ABI" choice, which defaults to CONFIG_FP_HARDABI. Both FP_HARDABI and FP_SOFTABI permit the compiler to emit hardware FP instructions in any function, even code that never uses floating-point types. However, the callee-saved FP registers (s16-s31 / d8-d15) are only saved and restored across a context switch when CONFIG_FPU_SHARING is enabled (arch/arm/core/cortex_m/swap_helper.S and arch/arm/core/cortex_a_r/swap_helper.S), and prior to this fix selecting an ABI did not enable FPU register sharing, which defaults off.
In a build that enables the FPU with the default ABI but leaves CONFIG_FPU_SHARING disabled, the kernel preserves no callee-saved FP register state across thread switches. The documented precondition for this "unshared" mode - that only a single thread ever executes FP instructions - is silently violated because the compiler may generate FP instructions in every thread.
Under CONFIG_USERSPACE, where threads are mutually isolated, this becomes an information-disclosure boundary crossing: a victim thread can leave secret-derived values in s16-s31, and a co-resident unprivileged thread can read those registers directly (FP register access is not privilege-gated), recovering data left behind by another thread. Without userspace the same defect causes cross-thread FP state corruption (a correctness fault). The leak is bounded to the 16 callee-saved single-precision registers and is opportunistic, so impact is low.
The fix makes FP_HARDABI and FP_SOFTABI select CONFIG_FPU_SHARING and tags every thread with K_FP_REGS at creation, so callee-saved FP state is always preserved across context switches whenever the compiler may emit FP instructions.
AnalysisAI
FPU register state leakage in Zephyr RTOS ARM port exposes callee-saved floating-point registers across thread boundaries when CONFIG_FPU is enabled without CONFIG_FPU_SHARING. Under CONFIG_USERSPACE builds, an unprivileged co-resident thread can directly read FP registers s16-s31 left behind by a victim thread after a context switch, because FP register access is not privilege-gated on ARM and the kernel performs no save/restore of those registers in the unshared configuration. No public exploit is identified at time of analysis, EPSS data is not provided, and the vulnerability is not listed in CISA KEV; impact is bounded to 16 callee-saved single-precision registers and requires an attacker-controlled thread executing concurrently with the victim.
Technical ContextAI
Zephyr RTOS is an open-source real-time operating system targeting resource-constrained embedded and IoT devices, with primary ARM Cortex-M and Cortex-A/R support. The ARM hard-float and soft-float ABIs (CONFIG_FP_HARDABI / CONFIG_FP_SOFTABI) permit the compiler to emit hardware FP instructions in any function, even for code with no explicit floating-point types, because the compiler may use FP registers for scratch or general-purpose work. The ARM calling convention designates s16-s31 (d8-d15) as callee-saved registers: the callee must preserve them. Zephyr's context switch routines in arch/arm/core/cortex_m/swap_helper.S and arch/arm/core/cortex_a_r/swap_helper.S save and restore these registers only when CONFIG_FPU_SHARING is enabled. The documented assumption for the unshared mode is that only a single thread ever uses FP instructions - but with either ABI enabled, the compiler silently violates this assumption across all threads. CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) directly describes the root cause: a security boundary (CONFIG_USERSPACE thread isolation) fails to protect callee-saved FP register state because the kernel never clears or saves those registers on context switch.
RemediationAI
The upstream fix is available via commit 3d405326a7653cba6860280e45c8734f8d3fc423 (https://github.com/zephyrproject-rtos/zephyr/commit/3d405326a7653cba6860280e45c8734f8d3fc423), which modifies arch/arm/core/Kconfig so that selecting FP_HARDABI or FP_SOFTABI automatically selects CONFIG_FPU_SHARING, and tags every thread with K_FP_REGS at creation in both cortex_m/thread.c and cortex_a_r/thread.c. A patched tagged release version has not been independently confirmed from the available data - consumers should check the Zephyr release notes and GHSA-qxr9-wh3c-hvgv for a confirmed stable release incorporating this commit. As an immediate workaround prior to patching, explicitly set CONFIG_FPU_SHARING=y in your project's prj.conf or Kconfig fragment; this forces the kernel to save and restore callee-saved FP registers on every context switch and eliminates both the information-disclosure and the corruption defect, at the cost of a modest increase in context-switch latency and per-thread stack usage for the saved FP register frame.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today