A crashing input in the initial corpus aborts the fuzzer with "No interesting cases found"

Aperta
  • Qualcosa non va?
#455 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
security, testing-qa

Direzione di ricerca

The abort comes from the initial corpus loading path in src/fuzzer/mod.rs around line 465, which prints the "No interesting cases found" message. Reproduce with tests/x86_64_magic_crash_latest.rs using the crash and normal seeds listed in the issue, and trace how a crash during load_initial_inputs is reported back, referring to #400 and #404. Done means the benign input runs and is counted, and the session no longer aborts when a crashing seed is present.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

When the initial corpus contains an input that crashes, the fuzzer records the crash and then aborts during initial corpus loading, even though the corpus also contains a valid, non-crashing input:

[tsffs info] Fuzzer message: [Objective #0] run time: 0h-0m-1s, clients: 1, corpus: 0, objectives: 1, executions: 1, exec/sec: 0.000
No interesting cases found from inputs! This may mean your harness is incorrect (check your arguments), your inputs are not triggering new code paths, or all inputs are causing crashes.: src/fuzzer/mod.rs:465:21

Only one execution happens, so the benign input never seems to run (or is not counted as interesting).

Impact

Seeding a known crashing input, for example to reproduce a bug or keep a regression in the corpus, makes the whole session abort at start-up.

Reproduction

Seen on main with #449 (reverted in #454), on Linux Simics 6 and 7: https://github.com/intel/tsffs/actions/runs/43357200336/job/131716849666

tests/x86_64_magic_crash_latest.rs with:

.files([
    ("corpus/crash".to_string(), b"fuzzing!".to_vec()),   // page faults in tests/rsrc/x86_64-crash-uefi
    ("corpus/normal".to_string(), b"AAAAAAAA".to_vec()),  // runs normally
])

and generate_random_corpus = False, exceptions = [14], quit_on_iteration_limit = False.

Notes

  • LibAFL (rev 0f26f6ea) loads initial files in read_dir order and, for a Solution, calls discard_metadata on the map feedback, so a crashing input should not mark its edges as seen. That suggests the problem is on the TSFFS side: how a crash during load_initial_inputs is reported back (see #400, #404) or how the next testcase is run after the snapshot restore.
  • The timeout test (#393) passes with an objective seed plus a benign seed, so it may be specific to crashes/exceptions.
  • Once fixed, the stricter crash test from #449 can come back as the regression test.

🤖 Generated with Claude Code

Lingua principale
Rust
Stelle
335
Fork
26
Merge medio
1g 50m
PR unite (30g)
12

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di intel/tsffs

Tutte le issue di intel/tsffs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.