Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.6",
  "pubDate": "2026-08-11T05:17:11.780Z",
  "pubdate": "2026-08-11T05:17:11.780Z",
  "executiveSummary": "This vulnerability involves an information disclosure and state corruption flaw within the Zephyr ARM port concerning hardware Floating Point Unit (FPU) register management.\nThe vulnerability type is improper hardware register state preservation leading to cross-thread information disclosure and memory corruption.\nThe impact includes the exposure of secret-derived values residing in callee-saved FPU registers across isolated user-space threads, or cross-thread FP state corruption in non-userspace configurations.\nAffected systems include Zephyr builds targeting the ARM architecture where the hardware FPU is enabled (CONFIG_FPU) and the Floating Point ABI defaults to CONFIG_FP_HARDABI or CONFIG_FP_SOFTABI while CONFIG_FPU_SHARING is left disabled.\nThe risk implications are moderate under CONFIG_USERSPACE, allowing an unprivileged co-resident thread to read sensitive data left behind in registers by a victim thread.\nAttacker capabilities require the execution of an unprivileged co-resident thread within the same system to opportunistically read hardware registers.\nExploitation requirements include a build configuration where CONFIG_FPU is enabled with default ABI settings, CONFIG_FPU_SHARING is disabled, and the compiler emits hardware FP instructions across threads that violate the unshared mode precondition.",
  "technicalDetails": "The root cause of the vulnerability stems from a configuration discrepancy in the Zephyr ARM port where enabling the hardware FPU via CONFIG_FPU forces the Floating Point ABI choice, defaulting to CONFIG_FP_HARDABI. Both CONFIG_FP_HARDABI and CONFIG_FP_SOFTABI permit the compiler to emit hardware FP instructions in any function, including code that never explicitly uses floating-point types.\nHowever, the callee-saved FPU registers (s16-s31 / d8-d15) are only saved and restored across a context switch when CONFIG_FPU_SHARING is explicitly enabled in arch/arm/core/cortex_m/swap_helper.S and arch/arm/core/cortex_a_r/swap_helper.S.\nPrior to the fix, selecting an ABI did not automatically enable FPU register sharing, which defaults to off. In this unshared configuration, the kernel preserves no callee-saved FP register state across thread switches.\nThe documented precondition for unshared mode—stating that only a single thread ever executes FP instructions—is silently violated because the compiler generates FP instructions across arbitrary threads.\nUnder CONFIG_USERSPACE, where threads are mutually isolated, this defect transforms into an information-disclosure boundary crossing. A victim thread can leave secret-derived values in registers s16-s31, and a co-resident unprivileged thread can read those registers directly because FP register access is not privilege-gated.\nThe attack flow proceeds as follows: 1) A victim thread executes code compiled with hardware FP instructions, populating the callee-saved FPU registers s16-s31 with sensitive or secret-derived data. 2) A context switch occurs, but because CONFIG_FPU_SHARING is disabled, the kernel fails to save the callee-saved FP register state. 3) An unprivileged co-resident attacker thread is scheduled on the CPU. 4) The attacker thread accesses the FPU registers directly without privilege restrictions. 5) The attacker recovers the data left behind by the victim thread, resulting in opportunistic information disclosure.\nWithout userspace enabled, the exact same defect causes cross-thread FP state corruption, resulting in a correctness fault. The leak is strictly bounded to the 16 callee-saved single-precision registers and remains opportunistic."
}