fuzzbug-fix

Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash

跳到安装

仓库: ChunMinChang/dotfiles
最近来源活动: 2026年2月21日 00:45
检测到的 SKILL.md 语言: 英语
星标: 0
分支: 0

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/ChunMinChang/dotfiles --skill fuzzbug-fix

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

SKILL.md

来源说明 · 只读预览

description	Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash
name	fuzzbug-fix
context	fork

Fuzzbug Fix Skill

This skill guides the analysis and fix of a fuzzing crash from the Mozilla fuzzing cluster.

General Principles

Before starting work, create a plan with one item per step below (Steps 1–6, including sub-steps). Present the plan to the user and get approval before proceeding.
Work headless (--headless on integration tests; not needed for gtest/xpcshell).
When stuck, need clarification, or need the user to manually check something, stop and discuss with the user rather than guessing.
Follow the steps in order for efficiency.

Step 1: Fetch Bug Details

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 for bug data

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.

Fetch bug data with bmo-to-md

If the user does not have local bug data:

Check that 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).
Check that a Bugzilla API key is configured: run 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.

Ask the user where to save the files, then download: 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.

Check for existing patches

After fetching, if there already seems to be a patch attached, stop and report this to the user, printing the bug URL.

Step 2: Verify Build Configuration

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.

Step 3: Create the Crashtest

If there is no test attachment (some bugs only have stack traces or minimal descriptions), skip to Step 3b: No Test Attachment.

Find the right directory

Crashtests live in crashtests/ subdirectories near the responsible code:

Search for existing crashtests/ directories near the component: find dom/media/crashtests or find layout/base/crashtests, etc.
The directory is almost always named crashtests (not crashtest).
If no crashtests/ directory exists nearby, look for the closest one in the parent module, or create one if appropriate.

Create the test file

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:

Always add a failsafe setTimeout for reftest-wait tests to prevent hangs.
Place support files (iframes, media files, etc.) next to the test file.
For media-related crashes, the test case from the fuzzer is often a binary file (e.g., .webm, .mp4, .ogg) — reference it in the HTML via <audio>, <video>, or new AudioContext().

Register the test in crashtests.list

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

Step 3b: No Test Attachment

When the bug has no test attachment (only a stack trace, crash signature, or description):

Analyze the bug directly: read the crash stack, regression range, and any bugmon comments.
Trace the code path: use searchfox-cli --define to read the relevant code from the crash stack. Identify the likely root cause.
Present your analysis to the user: show the code path, explain the reasoning for the likely cause, and propose a fix. Wait for user agreement before proceeding.
Once the user agrees with the analysis, try to generate a test (crashtest, gtest, or other appropriate format) that reproduces the issue. The test should fail or crash without the fix.
If generating a test is not feasible, discuss with the user whether to proceed with the fix without a regression test, or explore other testing approaches.

Step 4: Reproduce the Crash

Run the crashtest without the fix applied. The goal is to confirm it crashes.

Case 1: Crashes reliably

The test crashes on every run. This is the ideal case. Proceed to Step 5.

Case 2: Crashes intermittently

The crash is non-deterministic (e.g., due to race conditions). Try these approaches in order:

Run in a loop: use ./mach test <path> --headless --repeat N (e.g., --repeat 20) to run it multiple times.
Use Firefox chaos mode: set MOZ_CHAOSMODE=3 environment variable to introduce random scheduling jitter:
```
MOZ_CHAOSMODE=3 ./mach test <path> --headless --repeat 10
```

Load the machine: use 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.

Case 3: Does not crash

If the test never crashes even with the above techniques:

Verify the build configuration matches what the fuzzer used (check bug comments for ASan, debug, etc.).
Verify the test case is correct (right format, no corruption).
Discuss with the user — the test may require a specific build or environment.

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.

Step 5: Analyze and Fix

Read the crash details

Read the crash stack from the bug or from running the test locally.
Read the regression range if mentioned in bugmon comments.
The root cause is often not at the top stack frame — look deeper.

Investigate the code

Use searchfox-cli --define <ClassName::Method> to find the relevant code.
Start from the frame closest to the crash and work outward.
Check git log --oneline -20 -- <file> or git blame on suspicious areas, especially if a regression range is available.

Third-party / vendored code

If the crash is in third-party code (libvpx, ffvpx, libdav1d, cubeb, libopus, libaom, etc.):

Check if this is a known upstream issue — search the upstream bug tracker.
Prefer upstream fixes: if there's already an upstream fix, the right approach is to update the vendored library (see /update-media-lib skill).
Mozilla-side workaround: if the upstream fix is complex or unavailable, a workaround at the Mozilla integration layer may be appropriate (e.g., input validation before calling into the library).
Discuss with the user before deciding — upstream updates vs. local workarounds have different trade-offs for maintenance.

Common crash type patterns

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.

Propose the fix

Suggest a fix and explain your reasoning.
Think about whether the fix changes any Web Standards behavior — inform the user if so (this should almost never happen).

Verify the fix

Apply the fix and rebuild: ./mach build
Run the crashtest again — it should not crash and not hang.
For intermittent crashes, run multiple times with chaos mode to confirm.

Step 6: Finalize

Ask the user about creating a patch

Ask the user:

Patch format: what format do they want?
- Git commit (via /patch skill)
- git format-patch file
- Plain diff file
- Just show the diff (for manual handling)
Commit 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 MediaDecoder
- Bug XXXXXX - Add validation for buffer size in AudioData::CopyTo
- Bug XXXXXX - Handle edge case in WebAudio graph processing
Bad (reveals vulnerability) examples:
- Bug XXXXXX - Fix use-after-free in MediaDecoder::Shutdown
- Bug XXXXXX - Fix heap buffer overflow when parsing VP9
- Bug XXXXXX - Fix null dereference crash in AudioNode
Always 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.

Cleanup

If bug files were downloaded to a folder, ask the user if they want to keep them (for reference) or clean them up.

When You're Stuck

If you get stuck at any point:

Stop and discuss with the user rather than guessing or trying random things.
Explain what you've tried and what's not working.
Ask for manual verification if needed (e.g., "can you check if this crashes when you run it?").

If running as a sub-agent, exit the sub-agent. If not, just stop.

description	Analyze and fix a bug found by a fuzzer, fuzzbug, fuzz crash
name	fuzzbug-fix
context	fork

Fuzzbug Fix Skill

This skill guides the analysis and fix of a fuzzing crash from the Mozilla fuzzing cluster.

General Principles

Before starting work, create a plan with one item per step below (Steps 1–6, including sub-steps). Present the plan to the user and get approval before proceeding.
Work headless (--headless on integration tests; not needed for gtest/xpcshell).
When stuck, need clarification, or need the user to manually check something, stop and discuss with the user rather than guessing.
Follow the steps in order for efficiency.

Step 1: Fetch Bug Details

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 for bug data

Fetch bug data with bmo-to-md

If the user does not have local bug data:

Check that 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).
Check that a Bugzilla API key is configured: run 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.

Ask the user where to save the files, then download: 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.

Check for existing patches

After fetching, if there already seems to be a patch attached, stop and report this to the user, printing the bug URL.

Step 2: Verify Build Configuration

Step 3: Create the Crashtest

If there is no test attachment (some bugs only have stack traces or minimal descriptions), skip to Step 3b: No Test Attachment.

Find the right directory

Crashtests live in crashtests/ subdirectories near the responsible code:

Search for existing crashtests/ directories near the component: find dom/media/crashtests or find layout/base/crashtests, etc.
The directory is almost always named crashtests (not crashtest).
If no crashtests/ directory exists nearby, look for the closest one in the parent module, or create one if appropriate.

Create the test file

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:

<!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:

Always add a failsafe setTimeout for reftest-wait tests to prevent hangs.
Place support files (iframes, media files, etc.) next to the test file.
For media-related crashes, the test case from the fuzzer is often a binary file (e.g., .webm, .mp4, .ogg) — reference it in the HTML via <audio>, <video>, or new AudioContext().

Register the test in crashtests.list

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

Step 3b: No Test Attachment

When the bug has no test attachment (only a stack trace, crash signature, or description):

Analyze the bug directly: read the crash stack, regression range, and any bugmon comments.
Trace the code path: use searchfox-cli --define to read the relevant code from the crash stack. Identify the likely root cause.
Present your analysis to the user: show the code path, explain the reasoning for the likely cause, and propose a fix. Wait for user agreement before proceeding.
Once the user agrees with the analysis, try to generate a test (crashtest, gtest, or other appropriate format) that reproduces the issue. The test should fail or crash without the fix.
If generating a test is not feasible, discuss with the user whether to proceed with the fix without a regression test, or explore other testing approaches.

Step 4: Reproduce the Crash

Run the crashtest without the fix applied. The goal is to confirm it crashes.

Case 1: Crashes reliably

The test crashes on every run. This is the ideal case. Proceed to Step 5.

Case 2: Crashes intermittently

The crash is non-deterministic (e.g., due to race conditions). Try these approaches in order:

Run in a loop: use ./mach test <path> --headless --repeat N (e.g., --repeat 20) to run it multiple times.
Use Firefox chaos mode: set MOZ_CHAOSMODE=3 environment variable to introduce random scheduling jitter:
```
MOZ_CHAOSMODE=3 ./mach test <path> --headless --repeat 10
```

Load the machine: use 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.

Case 3: Does not crash

If the test never crashes even with the above techniques:

Verify the build configuration matches what the fuzzer used (check bug comments for ASan, debug, etc.).
Verify the test case is correct (right format, no corruption).
Discuss with the user — the test may require a specific build or environment.

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.

Step 5: Analyze and Fix

Read the crash details

Read the crash stack from the bug or from running the test locally.
Read the regression range if mentioned in bugmon comments.
The root cause is often not at the top stack frame — look deeper.

Investigate the code

Use searchfox-cli --define <ClassName::Method> to find the relevant code.
Start from the frame closest to the crash and work outward.
Check git log --oneline -20 -- <file> or git blame on suspicious areas, especially if a regression range is available.

Third-party / vendored code

If the crash is in third-party code (libvpx, ffvpx, libdav1d, cubeb, libopus, libaom, etc.):

Check if this is a known upstream issue — search the upstream bug tracker.
Prefer upstream fixes: if there's already an upstream fix, the right approach is to update the vendored library (see /update-media-lib skill).
Mozilla-side workaround: if the upstream fix is complex or unavailable, a workaround at the Mozilla integration layer may be appropriate (e.g., input validation before calling into the library).
Discuss with the user before deciding — upstream updates vs. local workarounds have different trade-offs for maintenance.

Common crash type patterns

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.

Propose the fix

Suggest a fix and explain your reasoning.
Think about whether the fix changes any Web Standards behavior — inform the user if so (this should almost never happen).

Verify the fix

Apply the fix and rebuild: ./mach build
Run the crashtest again — it should not crash and not hang.
For intermittent crashes, run multiple times with chaos mode to confirm.

Step 6: Finalize

Ask the user about creating a patch

Ask the user:

Patch format: what format do they want?
- Git commit (via /patch skill)
- git format-patch file
- Plain diff file
- Just show the diff (for manual handling)
Commit 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 MediaDecoder
- Bug XXXXXX - Add validation for buffer size in AudioData::CopyTo
- Bug XXXXXX - Handle edge case in WebAudio graph processing
Bad (reveals vulnerability) examples:
- Bug XXXXXX - Fix use-after-free in MediaDecoder::Shutdown
- Bug XXXXXX - Fix heap buffer overflow when parsing VP9
- Bug XXXXXX - Fix null dereference crash in AudioNode
Always 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.

Cleanup

If bug files were downloaded to a folder, ask the user if they want to keep them (for reference) or clean them up.

When You're Stuck

If you get stuck at any point:

Stop and discuss with the user rather than guessing or trying random things.
Explain what you've tried and what's not working.
Ask for manual verification if needed (e.g., "can you check if this crashes when you run it?").

If running as a sub-agent, exit the sub-agent. If not, just stop.

fuzzbug-fix

来源信息

安装方式

检查来源文件

同仓库更多 Skills

同仓库更多 Skills

Fuzzbug Fix Skill

General Principles

Step 1: Fetch Bug Details

Ask the user for bug data

Fetch bug data with bmo-to-md

Check for existing patches

Step 2: Verify Build Configuration

Step 3: Create the Crashtest

Find the right directory

Create the test file

Register the test in crashtests.list

Step 3b: No Test Attachment

Step 4: Reproduce the Crash

Case 1: Crashes reliably

Case 2: Crashes intermittently

Case 3: Does not crash

Step 5: Analyze and Fix

Read the crash details

Investigate the code

Third-party / vendored code

Common crash type patterns

Propose the fix

Verify the fix

Step 6: Finalize

Ask the user about creating a patch

Cleanup

When You're Stuck

Fuzzbug Fix Skill

General Principles

Step 1: Fetch Bug Details

Ask the user for bug data

Fetch bug data with bmo-to-md

Check for existing patches

Step 2: Verify Build Configuration

Step 3: Create the Crashtest

Find the right directory

Create the test file

Register the test in crashtests.list

Step 3b: No Test Attachment

Step 4: Reproduce the Crash

Case 1: Crashes reliably

Case 2: Crashes intermittently

Case 3: Does not crash

Step 5: Analyze and Fix

Read the crash details

Investigate the code

Third-party / vendored code

Common crash type patterns

Propose the fix

Verify the fix

Step 6: Finalize

Ask the user about creating a patch

Cleanup

When You're Stuck