菜单
Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Firefox bug triage assistant — fetches a Bugzilla bug via MCP, classifies signals, scopes searches to a media/web-conferencing/graphics/android profile, drafts a response, optionally generates a test page, and stages a pending draft you can apply to BMO via REST.
Firefox Bugzilla triage workflow for Codex. Use for polling or processing Bugzilla triage scopes, drafting comments, applying canned responses, and tracking pending triage actions.
Root cause analysis for Firefox bugs with evidence-based code tracing, permanent source links, and proof tests. Two phases: diagnose, then discuss solutions.
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.
Hypothesis-driven Firefox investigation: given a freeform suspicion that some code is buggy, unsafe, mis-behaving, or non-spec, blindspot validates the claim, finds real user-facing or security consequences (or proves there are none), and writes a bug-style report with revision-pinned code traces, original design intention from git history, and end-to-end proof tests. Triggers on: "/blindspot", "investigate this claim", "is this a real bug", "prove this is a bug", "find issues in <code>", "is this code safe", "what could go wrong with <code>".
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.
基于 SOC 职业分类
| 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.