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)
PoC verification
Evidence pack
findings/poc/DF-5557 Β· 3 files| File | Type | Description | Size | |
|---|---|---|---|---|
| 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 to0on every sigreturn, andnpxdna()(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_testablen/a β no reproduction possible on available hardware
n/a
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.
No comments yet.