CVE-2026-11985 in Zephyr
Summary
by MITRE • 08/11/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability exists within the Zephyr real-time operating system's ARM port where improper handling of floating-point unit configuration creates a security flaw in thread context switching mechanisms. When the hardware FPU is enabled through CONFIG_FPU, the system automatically selects the Floating Point ABI with a default setting of CONFIG_FP_HARDABI, which unlike FP_SOFTABI does not mandate the preservation of callee-saved registers during context switches.
This technical implementation flaw stems from the absence of automatic enabling of FPU register sharing when specific floating-point ABIs are selected. The kernel's swap helper implementations in both cortex_m and cortex_a_r architectures only save and restore the callee-saved FP registers s16-s31 and d8-d15 when CONFIG_FPU_SHARING is explicitly enabled, yet the ABI selection process fails to activate this crucial sharing mechanism.
The operational impact manifests differently depending on whether userspace isolation is enabled in the system configuration. In environments with CONFIG_USERSPACE active, where threads operate under mutual isolation, this vulnerability creates a direct information disclosure boundary crossing opportunity. A victim thread executing code that generates floating-point instructions can leave sensitive data in the callee-saved floating-point registers, which an unprivileged co-resident thread can directly access without privilege checks since FP register access is not gated by the system's privilege model.
Without userspace isolation, the same vulnerability results in cross-thread floating-point state corruption rather than information disclosure. This represents a correctness fault where one thread's floating-point computational state inadvertently contaminates another thread's execution context. The security implications are bounded to the 16 callee-saved single-precision registers but remain opportunistic in nature, potentially allowing data leakage between threads that execute floating-point code.
This vulnerability aligns with CWE-254 and CWE-782 categories related to improper privilege management and inadequate floating-point state handling within operating systems. The flaw also relates to ATT&CK techniques involving privilege escalation through information disclosure and resource hijacking via context switching mechanisms. The fix implements a comprehensive solution by automatically enabling CONFIG_FPU_SHARING when FP_HARDABI or FP_SOFTABI are selected, while also tagging all threads with K_FP_REGS at creation time to ensure consistent preservation of callee-saved floating-point state across all context switches whenever the compiler may emit floating-point instructions.
The resolution addresses the root cause by establishing a mandatory FPU sharing mechanism that operates regardless of whether userspace is enabled, ensuring thread isolation boundaries are properly maintained even when floating-point operations occur in any execution context. This approach prevents both information disclosure and state corruption scenarios while maintaining system correctness across all configurations where floating-point computation may be present.