hesela.devSemantic filesystem fuzzing
Semantic filesystem fuzzing generates filesystem inputs and checks their effects against explicit behavioral rules, including errors that do not crash the kernel.
Exploration and checking: Hydra combines input mutation with pluggable checkers; its released artifact includes the SymC3 recovery checker. A sanitizer-only campaign does not establish persistence or API conformance. [3]
Allowed outcomes: SymC3 models a set of permitted recovered states. Comparing against one reference image can reject another legitimate outcome. The oracle must match the selected filesystem contract. [1]
Input dimensions: Janus mutates metadata and image-dependent operations, repairing metadata checksums to reach deeper code. Its evaluated executor did not support DAX without modification. Repaired checksums do not make deliberately altered metadata trustworthy. [2]
Relations
- related
- Crash-test oracle, Bounded crash testing, Fault model, Crash refinement, Filesystem consistency invariant, Checksum
Limitations
- A clean run covers only the exercised inputs and enabled checks; it is not a proof that other states are safe. [1]
Citations
- Kim et al. Finding Semantic Bugs in File Systems with an Extensible Fuzzing Framework. SOSP 2019, sections 3.4-3.7 and 6.
- Xu et al. Fuzzing File Systems via Two-Dimensional Input Space Exploration. IEEE S&P 2019, sections IV and VI.
- Hydra authors. README: checker, setup and compatibility; revision fd16457ba756ed602ab8fca378458838cea8e409.
Further reading
Sources & caveats
- Primary-source review, not a new fuzzing campaign or present-day vulnerability claim. Historical tool and executor scope retained.
- Hydra SOSP 2019 DOI: 10.1145/3341301.3359662. Source sections reviewed beyond the abstract; no bug-count or performance comparison reproduced.