Menu
Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Hypothesis-driven Firefox investigation for Codex. Use when a user has a suspicious code pattern, potential security issue, suspected spec violation, or vague claim and wants to prove whether it is a real bug, find consequences, and write proof tests.
Create a Firefox patch from local changes. Use when the user wants Codex to inspect modified files, draft or polish a commit message, and prepare a patch without adding Codex co-authorship.
Fix Firefox fuzzing bugs. Use for fuzzing reports, crash reducers, sanitizer failures, testcase minimization, root-cause debugging, and proof-oriented Firefox fixes.
Independent red-team review for Firefox root-cause analyses and proposed fixes. Use to critique an analysis, patch, Phabricator revision, commit, diff, or working tree with isolated Codex subagents and structured verdicts.
Firefox bug root-cause analysis for Codex. Use for Bugzilla bugs or Firefox failures where you need evidence-based diagnosis, revision-pinned source links, code-path tracing, proof tests, resumable run directories, and later solution discussion.
Firefox Bugzilla triage workflow for Codex. Use for polling or processing Bugzilla triage scopes, drafting comments, applying canned responses, and tracking pending triage actions.
| description | Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash |
| name | fuzzbug-fix |
| context | fork |
This skill guides the analysis and fix of a fuzzing crash from the Mozilla fuzzing cluster.
--headless on integration tests; not needed for gtest/xpcshell).Most fuzz bugs are private and cannot be fetched via the MCP tool
mcp__moz__get_bugzilla_bug. Use local files or bmo-to-md instead.
Ask the user whether they already have a local bug report (markdown files from
bmo-to-md), and if so, where the files are located. If they provide a path,
read the summary file there and skip to
Check for existing patches.
If the user does not have local bug data:
bmo-to-md is installed: run bmo-to-md --help. If not found,
ask the user to install it: cargo install bmo-to-md
(see https://github.com/padenot/bmo-to-md).echo $BMO_API_KEY. If
empty, ask the user to set it up — they need to generate an API key from
their Bugzilla account preferences and either export BMO_API_KEY in their
shell or create ~/.config/bmo-to-md/config.toml with api_key = "...".If either prerequisite is missing, stop and report to the user. Do not proceed without both.
bmo-to-md -o <folder> -a <bug_id>If bmo-to-md fails, stop and report — there is no alternative for private
bugs. Do not use /tmp or temporary locations.
After fetching, if there already seems to be a patch attached, stop and report this to the user, printing the bug URL.
Check the mozconfig at the root of the repo. Verify this is a debug build
(look for --enable-debug or ac_add_options --enable-debug).
--enable-fuzzing is unrelated and not needed for reproducing most fuzz bugs.
If the mozconfig looks wrong or doesn't exist, inform the user and suggest using
the /mozconfig skill to generate an appropriate debug configuration. Some bugs
may require specific build configurations (e.g., ASan, TSan). Check the bug
comments for hints about which configuration was used by the fuzzer.
If there is no test attachment (some bugs only have stack traces or minimal descriptions), skip to Step 3b: No Test Attachment.
Crashtests live in crashtests/ subdirectories near the responsible code:
crashtests/ directories near the component:
find dom/media/crashtests or find layout/base/crashtests, etc.crashtests (not crashtest).crashtests/ directory exists nearby, look for the closest one in the
parent module, or create one if appropriate.Name the file after the bug number: <bug_number>.html (or .xhtml if needed).
Minimal crashtest (synchronous):
<!DOCTYPE html>
<html>
<body>
<script>
// Code that triggers the crash
</script>
</body>
</html>
Async crashtest with reftest-wait:
Use class="reftest-wait" on the root <html> element when the crash requires
asynchronous operations (resource loading, media playback, event handlers, etc.).
Remove the class when the test is ready to signal completion:
<!DOCTYPE html>
<html class="reftest-wait">
<body>
<script>
// Set up async operation...
someAsyncThing.onload = function() {
// Test logic here
document.documentElement.removeAttribute("class");
};
// Add a failsafe timeout to prevent hangs:
setTimeout(() => {
document.documentElement.removeAttribute("class");
}, 5000);
</script>
</body>
</html>
Key patterns:
setTimeout for reftest-wait tests to prevent hangs..webm, .mp4, .ogg) — reference it in the HTML via
<audio>, <video>, or new AudioContext().Add a line to the crashtests.list file in the same directory:
load <bug_number>.html
Common syntax patterns:
load 1234567.html # simple
skip-if(Android) load 1234567.html # skip on Android
skip-if(ThreadSanitizer) load 1234567.html # skip under TSan
skip-if(isDebugBuild) load 1234567.html # bug NNNNN # skip in debug with comment
When the bug has no test attachment (only a stack trace, crash signature, or description):
searchfox-cli --define to read the relevant
code from the crash stack. Identify the likely root cause.Run the crashtest without the fix applied. The goal is to confirm it crashes.
The test crashes on every run. This is the ideal case. Proceed to Step 5.
The crash is non-deterministic (e.g., due to race conditions). Try these approaches in order:
./mach test <path> --headless --repeat N (e.g.,
--repeat 20) to run it multiple times.MOZ_CHAOSMODE=3 environment variable to
introduce random scheduling jitter:
MOZ_CHAOSMODE=3 ./mach test <path> --headless --repeat 10
stress-ng to add CPU/memory pressure that makes
race conditions more likely:
stress-ng --cpu $(nproc) --timeout 60 &
MOZ_CHAOSMODE=3 ./mach test <path> --headless --repeat 10
If it crashes at least once across multiple runs, that is sufficient — CI runs many jobs and will eventually trigger the bug.
If the test never crashes even with the above techniques:
Important: the crashtest itself must be error-free (no JS errors, no missing resources). Errors other than the crash indicate a problem with the test.
searchfox-cli --define <ClassName::Method> to find the relevant code.git log --oneline -20 -- <file> or git blame on suspicious areas,
especially if a regression range is available.If the crash is in third-party code (libvpx, ffvpx, libdav1d, cubeb, libopus, libaom, etc.):
/update-media-lib skill).| Crash Type | Typical Indicators | Common Fix Approaches |
|---|---|---|
| Use-after-free | ASan report "heap-use-after-free", accessing freed memory | Fix the ownership/prevent access after free. Often involves preventing deletion of ref-counted/prevent access after release. Don't just null-check — fix the lifetime. |
| Null dereference | SIGSEGV at low address, null pointer in stack | Check why the pointer is null — may indicate an unexpected state. A null check is sometimes correct, but may mask a deeper issue. |
| Buffer overflow | ASan "heap-buffer-overflow" or "stack-buffer-overflow" | Fix bounds checking. Usually a missing length/size validation on input data. |
| Assertion failure | MOZ_ASSERT / MOZ_CRASH triggered | The assertion is usually correct — the bug is reaching that state. Fix the code path that leads to the invalid state, not the assertion. |
| Integer overflow | Large values causing unexpected behavior, CheckedInt failures | Add overflow checks before the arithmetic. Use CheckedInt or validate input bounds. |
| OOM / allocation failure | Very large allocation sizes from malformed input | Validate sizes from untrusted input before allocating. Return error/reject rather than proceeding. |
Important: avoid purely local fixes for systemic problems. A band-aid
if (!ptr) return; will likely be rejected at review if the real problem is a
lifetime issue. Think about why the bad state occurs.
./mach buildAsk the user:
Patch format: what format do they want?
/patch skill)git format-patch fileCommit message: for security-sensitive bugs (most fuzz bugs are), the commit message should be deliberately ambiguous — do not reveal the nature of the vulnerability.
Good (ambiguous) examples:
Bug XXXXXX - Improve bounds checking in MediaDecoderBug XXXXXX - Add validation for buffer size in AudioData::CopyToBug XXXXXX - Handle edge case in WebAudio graph processingBad (reveals vulnerability) examples:
Bug XXXXXX - Fix use-after-free in MediaDecoder::ShutdownBug XXXXXX - Fix heap buffer overflow when parsing VP9Bug XXXXXX - Fix null dereference crash in AudioNodeAlways show the proposed commit message to the user for review before creating the patch.
Reviewer: suggest a reviewer by inspecting git blame around the fixed
code.
If the user wants a git commit, delegate to the /patch skill.
If bug files were downloaded to a folder, ask the user if they want to keep them (for reference) or clean them up.
If you get stuck at any point:
If running as a sub-agent, exit the sub-agent. If not, just stop.