14.8 Billion Fuzz

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 primitives are intended to become foundational infrastructure components.

The Fix

The invariant was rewritten to start from ZERO instead:

let mut acc_even = FixedHash::ZERO;

for _ in 0..8 {

acc_even = acc_even ^ h;

}

Now the parity logic is mathematically correct.

Final Thoughts

One thing I’ve learned while building infrastructure software:

Most failures do not come from “complex” code.

They come from small assumptions that quietly survive code review, testing, and intuition.

Fuzzing is one of the few tools brutal enough to challenge those assumptions continuously.

And sometimes, the most valuable bug is the one that proves the primitive was right all along.