On Zephyr ARM platforms, enabling the hardware FPU (CONFIG_FPU) forces a floating point ABI choice defaulting to CONFIG_FP_HARDABI. Both FP_HARDABI and FP_SOFTABI allow the compiler to emit hardware floating point instructions in any function, even those not explicitly using floating point types. However, callee-saved floating point registers (s16-s31 / d8-d15) are only saved and restored across context switches if CONFIG_FPU_SHARING is enabled. Prior to the fix, selecting an ABI did not enable FPU register sharing, which defaults to off. This leads to a scenario where the kernel does not preserve callee-saved FP register state across thread switches. Under CONFIG_USERSPACE, this causes an information disclosure boundary violation because unprivileged threads can read FP registers left by victim threads, as FP register access is not privilege-gated. Without userspace, this causes cross-thread FP state corruption. The vulnerability is bounded to 16 registers and is opportunistic, resulting in low impact. The fix makes FP_HARDABI and FP_SOFTABI select CONFIG_FPU_SHARING and tags threads with K_FP_REGS to ensure preservation of FP state across context switches.

The vulnerability allows an unprivileged thread to read floating point registers left behind by another thread, causing information disclosure of data stored in those registers. The leak is limited to 16 callee-saved single-precision floating point registers and is opportunistic, resulting in low impact. Without userspace isolation, it causes cross-thread floating point state corruption, which is a correctness fault rather than a security breach.

A patch is available that enables CONFIG_FPU_SHARING automatically when FP_HARDABI or FP_SOFTABI is selected, ensuring callee-saved floating point registers are preserved across context switches. Users should apply the official fix to prevent information leakage. Since this is a cloud service, the vendor manages remediation server-side; check the vendor advisory for confirmation and deployment status.