Rabah Laouadi Posted on Jun 1 14.8 Billion Fuzz # programming # rust # cybersecurity # security How 14.8 Billion Fuzz Executions Exposed an XOR Invariant Trap in a Rust Kernel Primitive For the past weeks, I’ve been building and stress-testing a minimal kernel layer for a long-term Rust infrastructure project. The focus is intentionally narrow: deterministic primitives zero-allocation types stable binary representations no hidden runtime behavior strict invariant enforcement Recently, I ran a long adversarial fuzzing campaign against the kernel primitives. The campaign crossed roughly 14.8 billion executions. At first, the interesting part seemed to be the crashes themselves. But the second crash turned out to be far more interesting than a typical memory bug. The Crash The fuzzer eventually stopped on this assertion: assertion failed: acc_even.ct_eq(&FixedHash::ZERO) At first glance, this looked like a potential issue in the XOR implementation of the hash primitive. That would have been serious. Especially in low-level deterministic infrastructure where algebraic guarantees matter. The Investigation The fuzz target contained a chained XOR stress test: let mut acc_even = h; for _ in 0..8 { acc_even = acc_even ^ h; } The invariant incorrectly assumed: «even XOR count ⇒ ZERO» But there was a subtle mistake. The accumulator was already initialized with "h". That means the expression actually evaluated to: h ^ h ^ h ^ h ^ h ^ h ^ h ^ h ^ h Not 8 occurrences. 9 occurrences. And XOR parity rules are strict: even occurrences ⇒ ZERO odd occurrences ⇒ ORIGINAL So the primitive was correct. The verification logic was wrong. Why This Matters This is exactly why long-running fuzzing campaigns are valuable even for “simple” primitives. The goal is not only to find crashes. The goal is to validate assumptions. In low-level systems engineering, incorrect assumptions inside verification layers can become just as dangerous as implementation bugs themselves. Especially when those
LIVE