FP-DSS: Floating Point Divider State Sampling

In this blog post, we discuss Floating Point Divider State Sampling (FP-DSS), a new transient execution attack that allows an attacker to infer data from floating point instruction execution on AMD Zen and Zen+ microarchitectures.

AMD assigned CVE-2025-54505 to the vulnerability and discusses their recommendations in their security bulletin AMD-SB-7053. AMD also informs that they are working with upstream OS maintainers to deploy the mitigation. Xen discussed their applied mitigations their security advisory. In the following, we discuss the general vulnerability, what an attacker can do with it, and how to mitigate it. Note that the following is based on our understanding of the vulnerability, is subject to change, and does not represent AMD’s official position on the vulnerability. The Proof-of-Concept code can be found in our GitHub repository.

# Overview

Using our new vulnerability detection framework TREVEX, we discovered leakage between floating-point instructions on AMD Zen and Zen+ microarchitectures. We refer to this vulnerability as Floating Point Divider State Sampling (FP-DSS). FP-DSS allows an attacker to leak the operands of previous SSE and AVX divisions executed on the same CPU core, including from other SMT threads.

A vulnerable scenario arises when an application executes an AVX or SSE division instruction, e.g., the AVX instruction vdivss xmm3, xmm1, xmm2, and its operands (xmm1 and xmm2) contain confidential information. Now assume an attacker can execute code on the same system, for example, by running their own application or by executing JavaScript code in a browser. The attacker then issues another AVX division instruction, e.g., another vdivss xmm3, xmm1, xmm2. To trigger the leakage reliably, the attacker picks denormal numbers as operands, e.g., picking xmm1 and xmm2 as 0x1 (raw value), which represents the floating point value 1.40129846432481707092e-45. Executing the division with such operands triggers a microcode assist, which opens a transient window in which the attacker can transiently encode and thus leak the result of the division instruction, for example, using a cache covert channel. What we found is that the transiently encoded value depends on the operands of the victim’s division instruction, or, to be more precise, on the operands of the last AVX division instruction executed on the same CPU core. We hypothesize that the leakage stems from an intermediate state of the floating-point division execution unit. SSE divisions are affected in the same way. When the attacker executes an SSE division, they leak values from previous SSE divisions. We could not confirm any cross-leakage between SSE and AVX, i.e., executing an AVX division does not leak values from previous SSE divisions, nor vice versa.

# Exploitation Scope

FP-DSS does not require any special privileges or fault handling, allowing for versatile exploitation as long as the attacker can execute code on the same system as their victim. We verified FP-DSS exploitation from native C code and from JavaScript combined with WebAssembly inside Google Chrome. For exploitation within Chrome, we used WebAssembly’s f64.div instruction and encoded the division’s result into an Uint8Array array. Finally, we used Evict+Reload to recover the accessed index from the array, leaking the transient result of the division.

We further verified that native userspace code can leak data from the Linux kernel, despite the kernel’s use of amd_clear_divider(), the mitigation deployed against Divider State Sampling (see below). Although we did not evaluate hypervisors explicitly, it is likely that they are affected in a similar manner.

To reason about the leakage rate that FP-DSS can achieve, we created a covert channel in native C that transmits data at 159 kbit/s with an error rate of 0.38%.

# Comparison to Divider State Sampling (DSS)

We chose the name Floating Point Division State Sampling (FP-DSS) as the vulnerability shares certain similarities with the Divider State Sampling (DSS) vulnerability that Hofman et al. disclosed in 2023. However, DSS leaks information from integer divisions, affects a different set of CPUs, and requires fault handling. While DSS and FP-DSS both affect some AMD Zen 1 CPUs, the machines that we discovered FP-DSS on (Ryzen 5 2500U and Ryzen 5 3550H) are not affected by DSS. Furthermore, FP-DSS is not affected by the currently active DSS mitigations for DSS (see below for more details). We hypothesize that this is because FP-DSS leaks intermediate results of the floating-point division execution unit, while DSS leaks from the integer division execution unit. In contrast to DSS, which requires an exception triggered by a division-by-zero, FP-DSS does not require an exception at all, as it is triggered by non-faulting divisions. Hence, FP-DSS can be exploited from contexts where faulting instructions are not possible or fault handling is restricted, for example, within a browser.

# How Did We Find It?

We found FP-DSS with an automated vulnerability detection framework TREVEX. TREVEX is discussed in detail in our paper accepted at IEEE Symposium on Security and Privacy 2026. The paper is published under the title “TREVEX: A Black-Box Detection Framework For Data-Flow Transient Execution Vulnerabilities” and is available online, additionally its code is available on GitHub.

# Mitigation

To mitigate FP-DSS, AMD recommends setting bit 9 of MSR 0xC0011028. While the exact behavior of this bit is not publicly documented, we confirmed that setting it prevents the leakage and AMD announced that they are working with upstream OS maintainers to deploy the mitigation. While we recommend following AMD’s proposed mitigation, an alternative approach would be to clear the microarchitectural state by issuing divisions on context switches, similar to previous mitigations for Linux and Xen:

void amd_clear_fp_dividers() {
    asm volatile(
        "movq   %[one], %%xmm1\n\t"
        "movq   %[one], %%xmm2\n\t"
        "divsd  %%xmm1, %%xmm2\n\t"
        "movq   %[one], %%xmm1\n\t"
        "movq   %[one], %%xmm2\n\t"
        "vdivss  %%xmm2, %%xmm1, %%xmm1\n\t"
        :: [one] "r"(1ull): "xmm1", "xmm2");
}

The snippet issues SSE and AVX divisions, which clear the divider state and prevent FP-DSS on context switches. According to our experiments, this prevents FP-DSS from leaking data across context switches, for example, from the Linux kernel to userspace. Note that an attacker running in parallel, e.g., on another SMT thread, can still exploit FP-DSS, which is why this mitigation would only be effective when SMT is disabled. Hence, we only list this mitigation for completeness, but we recommend following AMD’s proposed mitigation instead. For details on how Xen mitigates FP-DSS, we refer to their security advisory.