fuzz: fix kernel_params fuzzer crash on validation panics - #201
Merged
Conversation
std::process::exit flushes stdio and runs atexit handlers, which acquire locks. In a forked child of the multi-threaded test harness, a parallel test thread may hold the stderr mutex at fork time, leaving it permanently locked in the child. eprintln! and std::process::exit then deadlock, causing test_fork_agent_with_timeout to hang indefinitely. Replace with libc::write(2, ...) and libc::_exit, which are async-signal-safe and bypass all stdio/atexit locks. Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com> Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com>
zvonkok
force-pushed
the
fix/fuzz-kernel-params-result
branch
from
July 15, 2026 22:51
627e405 to
f3f240e
Compare
libc::_exit skips atexit handlers, which is where the LLVM profile runtime writes .profraw files. The forked children that panic in the kata_agent tests exited without recording coverage, dropping kata_agent.rs below the 90% per-file gate. Under cfg(coverage) call __llvm_profile_write_file() explicitly before _exit. The profraw pattern contains %p, so each child writes its own file without clobbering the parent's. Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com> Assisted-By: Claude Fable 5 <noreply@anthropic.com>
cargo-fuzz forces -C panic=abort via RUSTFLAGS, so catch_unwind is
silently a no-op: every .expect() call in the numeric parsers aborts
the process and libFuzzer records it as a crash.
Introduce try_process_kernel_params() returning Result<(), String> as
the Result-based twin of process_kernel_params(). The production API
is unchanged: process_kernel_params() delegates to the try_ variant
and unwrap_or_else(|e| panic!("{e}")) preserves fail-fast behavior.
The fuzz target calls try_process_kernel_params() so validation errors
(invalid freq/wattage) surface as Err and are ignored; any unexpected
panic from a genuine parser bug still aborts and is caught by libFuzzer.
Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com>
zvonkok
force-pushed
the
fix/fuzz-kernel-params-result
branch
from
July 15, 2026 23:01
f3f240e to
1d27728
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cargo-fuzz forces
-C panic=abortvia RUSTFLAGS. With that flag set,catch_unwindis silently a no-op: every.expect()in the numericparsers aborts the process and libFuzzer records it as a crash.
Introduce
try_process_kernel_params()returningResult<(), String>.The production API is unchanged:
process_kernel_params()delegates tothe
try_variant and.unwrap_or_else(|e| panic!("{e}"))preservesfail-fast behavior. The fuzz target calls
try_process_kernel_params()so validation errors (invalid freq/wattage) surface as
Errand areignored; genuine parser bugs still abort and are caught by libFuzzer.