β¬’ DragonFlyBSD Kernel Audit
← triage Β· dashboard
DF-5557

npxprobemask() lacks the mxcsr_mask==0 fallback guard β€” non-conforming FXSAVE probe zeroes npx_mxcsr_mask and SIGFPEs every FPU restore (DF-5526 twin)

Summary

The raw FXSAVE MXCSR_MASK word is stored with no zero check; the SDM requires substituting 0xFFBF when the field reads 0. On non-conforming host silicon every FP restore force-masks MXCSR to 0 -> every process's first SSE instruction SIGFPEs plus a console flood. Copy-paste twin of pc64 DF-5526, same missing guard. Hardware precondition absent on the rig (guest FXSAVE reports non-zero) - honest untested; one-line fallback fix documented.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-5557 Β· 3 files
FileTypeDescriptionSize
README.md β€” 2.4 KB ↓ raw
verdict.json β€” 1.9 KB view raw
manifest.json β€” 594 B view raw

DF-5557 β€” vkernel npxprobemask() lacks the mxcsr_mask == 0 fallback guard (DF-5526 twin)

What

sys/platform/vkernel64/x86_64/npx.c:112-123:

void npxprobemask(void)
{
    /*64-Byte alignment required for xsave*/
    static union savefpu dummy __aligned(64);

    crit_enter();
    /*stop_emulating();*/
    fxsave(&dummy);
    npx_mxcsr_mask = ((uint32_t *)&dummy)[7];   /* <-- no zero check */
    /*stop_emulating();*/
    crit_exit();
}

The Intel SDM (and the FXSAVE "Denormals are Zero" applicability note) say the MXCSR_MASK field of the FXSAVE image (offset 28, i.e. ((uint32_t*)&dummy)[7]) may be reported as 0 by non-conforming implementations, in which case software must use the default mask 0xFFBF. pc64's twin (sys/platform/pc64/x86_64/npx.c:126-137) has the identical missing guard (filed this pass as DF-5526); the vkernel copy-paste never got it either (and additionally cannot load_cr4(CR4_OSFXSR) β€” harmless: the host OS always sets OSFXSR for 64-bit processes).

Effect if it fires

npx_mxcsr_mask = 0 makes every later MXCSR "illegal":

  • npxpop() (npx.c:341-350) force-masks the restored MXCSR to 0 on every sigreturn, and npxdna() (npx.c:218-221) does the same on every FP restore β€” MXCSR=0 unmasks all six SIMD floating-point exceptions, so the first SSE instruction of the process raises SIGFPE;
  • a rate-limited "illegal FP MXCSR" flood is printed for every restore.

Pure correctness/robustness (no memory-unsafety, no info leak, no privilege impact); reachable only on a CPU whose FXSAVE reports a zero MXCSR_MASK. Severity Info.

Why no PoC

Requires non-conforming hardware (FXSAVE image with MXCSR_MASK==0). The audit guest's FXSAVE reports a non-zero mask (verified: the vkernel boots and restores FPU state without the SIGFPE storm), so the condition cannot be triggered on the available rig. Code-divergence from the SDM recommendation is structural and certain; runtime behavior is untested.

Fix

Mirror the SDM-recommended fallback (pc64 twin should take the same fix, see DF-5526):

--- a/sys/platform/vkernel64/x86_64/npx.c
+++ b/sys/platform/vkernel64/x86_64/npx.c
@@ -117,11 +117,14 @@ void npxprobemask(void)
    crit_enter();
    /*stop_emulating();*/
    fxsave(&dummy);
-   npx_mxcsr_mask = ((uint32_t *)&dummy)[7];
+   npx_mxcsr_mask = ((uint32_t *)&dummy)[7];
+   if (npx_mxcsr_mask == 0)
+       npx_mxcsr_mask = 0xFFBF;
    /*stop_emulating();*/
    crit_exit();
 }

Fix verification

not_testable
baseline no→ patch + rebuild →patched clean

n/a β€” no reproduction possible on available hardware

n/a
per-fix-DF-5557

Confirmed kernel references

Detail

Evidence (decisive lines)

README.md (full analysis + fix diff); no runtime artifacts β€” condition is hardware-dependent and absent on the rig

PoC changes

none (no PoC authored: hardware precondition not satisfiable on the rig)

Verified recommended fix

npxprobemask(): if the probed MXCSR mask word is 0, fall back to 0xFFBF

Verdict

Code-divergence certain by inspection (vkernel npxprobemask at sys/platform/vkernel64/x86_64/npx.c:120 stores the raw FXSAVE MXCSR_MASK word with no zero fallback, identical to pc64's DF-5526), but triggering it requires hardware whose FXSAVE reports MXCSR_MASK==0; the audit guest's FXSAVE reports a non-zero mask, so no runtime reproduction is possible on the available rig. Impact if it fires is correctness only: every FP restore force-masks MXCSR to 0, unmasking all SIMD exceptions and SIGFPE-ing the first SSE instruction of each process. Info severity hardening twin; fix is the SDM-recommended 0xFFBF fallback.