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

Abierto
  • ¿Algo no está bien?
#455 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
security, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
335
Forks
26
Merge medio
1 d 50 min
PR fusionados (30 d)
12

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de intel/tsffs

Todos los issues de intel/tsffs

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.