---
name: v8-v8-poc-classification
description: "Reproduces, heals (e.g., converting browser/HTML POCs to d8), minimizes, and classifies whether a V8 POC is a security vulnerability or a regular bug."
license: "NOASSERTION"
metadata:
  decimalai-skill-id: "42677b73-41df-4b94-9c2b-e7072ff49716"
  decimalai-version-id: "2085f509-2eee-4dca-8e43-37674f9e7a01"
  decimalai-version: "4"
  decimalai-body-sha256: "082ed0af3ee0dfcccdaf188bcf570ec54faa4ddd5e12d312cd1be7ca717c5094"
  decimalai-name: "v8/v8-poc-classification"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "security"
  decimalai-source: "https://app.decimal.ai/s/v8-v8-poc-classification@4/SKILL.md"
---
# Skill: V8 POC Classification

Use this skill to determine if a reported Proof-of-Concept (POC) crash is a
security vulnerability or a regular bug through empirical technical analysis.

## Core Mandates

- **Scope Limitation:** This skill is strictly for **technical analysis and
  classification**. It does NOT include implementing a fix.
- **Empirical Verification of ALL Claims:** Do not take ANY part of the
  reporter's classification or impact claims at face value. Every claim (e.g.,
  "arbitrary memory write", "sandbox escape", "silent write") MUST be
  empirically verified.
- **Verify with Debuggers:** A claim of memory corruption must be verified by
  observing the crash or memory state using debugging tools (GDB).
  - **Read vs. Write**: You MUST verify the faulting instruction type.
  - **Pointer Control**: Check if faulting addresses or register values are
    actually controlled by the attacker (e.g., contain values from the POC).
- **Mandatory Non-ASan Verification:** For any potential security bug, you MUST
  verify reproduction on a standard **Release build without ASan/UBSan**.
- **Autonomous Classification:** You are responsible for forming your own
  technical conclusion based on the rules in
  [triaging.md](../../../docs/security/triaging.md) and
  [reproducing-bugs.md](../../../docs/security/reproducing-bugs.md).

## Workflow

### 1. Initial Verification & Exhaustive Reproduction

Confirm the bug exists as reported.

- **Action**: Run `d8 <provided-flags> <poc.js>`.
- **Escalation**: If it doesn't reproduce, try multiple revisions (Reporter's
  commit and Main) and build configurations (Debug, ASan, Release).
- **Browser Web Worker Translation**: When converting a browser `Worker` POC
  (e.g., from `poc.html`) to `d8`, note that `d8` uses
  `new Worker(fn, {type: 'function'})`, passes messages directly to
  `onmessage = function(msg) { ... }` (not wrapped in `{data: msg}` like DOM
  `MessageEvent`), and receives messages on the main thread via
  `worker.getMessage()`.
- **Deep Dive**: Capture the initial backtrace and faulting instruction in GDB.
- **Check for Explicit Aborts:** Look for evidence that execution was
  intentionally terminated by V8 (e.g., via `SBXCHECK`, `FATAL`, or traps). If
  so, this is typically **Intended Behavior** (see guidelines below).

### 2. Security Boundary Investigation (The Filter)

Determine if the bug remains a vulnerability under production restrictions.

- **Action**: Run with `provided_flags + --run-as-[sandbox]-security-poc`.
- **Failure Loop (If reproduction stops)**:
  1. **Analyze**: Identify which flag or syntax is restricted. Is it
     `--allow-natives-syntax`? Is it an experimental compiler flag?
  2. **Heal**: Attempt to rewrite the POC to avoid the restriction.
     - *Example*: Replace `%OptimizeFunctionOnNextCall(f)` with a loop that
       triggers Tier-up: `for(let i=0; i<10000; i++) f();`.
     - *Example*: Replace `%ArrayBufferDetach(b)` with a standard way to
       detach/transfer if possible.
  3. **Conclude**: If the logic *requires* a restricted feature (like
     `--fuzzing` or a non-shipping experimental flag) to trigger the memory
     corruption, the report is likely a **Bug**, not a vulnerability.

### 3. Impact Assessment & Minimization

Technical proof of the vulnerability's severity.

- **Minimization**: Strip the POC and flags to the absolute minimum required to
  trigger the crash under the security POC flags.
  - **Flag Bisection**: If reproduction requires catch-all flags like
    `--future`, you MUST identify the minimal set of flags responsible for the
    behavior.
    - **Identify Implications:** Search `src/flags/flag-definitions.h` for flags
      implied by the reported flags.
    - **Check Production Defaults:** Verify if the identified flags are enabled
      or disabled by default in production.
    - **Systematic Testing:** Test each implied flag individually (or in groups)
      with the POC to pinpoint the specific optimization or feature at fault.
- **Impact Escalation**: If the bug exists but does NOT cause a crash (e.g., a
  "stale value" or "logical type confusion"), you MUST attempt to escalate it to
  a memory safety violation. Prove that the logical flaw can bypass V8's
  security boundaries.
  - **Techniques**: Type Confusion (misleading object layout), OOB Access (stale
    length), Pointer Overwrite (overwriting field/loop-carried pointer).
- **Verification**: Run the *minimized* POC on a **Standard Release build
  (non-ASan)**.
  - If it stops crashing or is caught by a hardened check (`SBXCHECK`, `FATAL`),
    classify it as **Intended Behavior** or a **Bug**.
- **Crashing POC for ClusterFuzz**: A crashing POC (segfault) is highly
  preferred for ClusterFuzz upload (see the `clusterfuzz` skill). Always try to
  provide a standalone `.js` file that crashes on a Release build.
- **Deep Dive (GDB)**:
  - Verify **Attacker Control**: Do registers or memory at the crash site
    reflect values set in the POC (e.g., `0x41414141`)?
  - **Read vs. Write**: Explicitly identify the primitive.
  - **Scope Analysis**: For logical bugs, use tracing flags (e.g.,
    `--trace-maglev-graph-building`) to confirm the discrepancy.
  - **Component Mapping**: Identify the specific V8 subsystem affected (e.g.,
    Maglev, Turbofan, Ignition, WebAssembly) to support component
    classification.

### 4. Classification Guidelines

The classification MUST be supported by empirical evidence from the local
reproduction:

- **Local Reproduction Findings** (keep sub-bullets to 1 concise line, except
  `GDB Backtrace` if multiple lines help):
  - **Status**: `Reproduced` / `Not Reproduced`.
  - **Reproduction**: `d8 <flags> <poc.js>` (filename only, omit local paths).
  - **Result**: 1–2 short sentences summarizing the output, crash, or sandbox
    violation.
  - **Build**: Build variant(s) (e.g., `x64.release`, `x64.asan`), V8 version
    (from `include/v8-version.h`), and revision number (from
    `Cr-Commit-Position`), skipping the git hash and with no link to Gerrit
    (only link to Gerrit and include the commit title when the specific *change*
    in a commit is important; omit boilerplate GN args).
  - **Verified Impact**: 1 sentence stating the verified primitive and attacker
    control.
  - **GDB Backtrace**: A concise snippet of the faulting instruction/registers
    and relevant stack frames (can span multiple lines if helpful; trim
    unrelated frames).

Read and apply [triaging.md](../../../docs/security/triaging.md) and
[reproducing-bugs.md](../../../docs/security/reproducing-bugs.md) for the
authoritative classification rules (`Type=Vulnerability` vs. `Type=Bug` vs.
intended behavior, regular bugs vs. sandbox bypasses, flag restrictions, and
special cases).

- **Debugging Indicators for Safe Termination (Intended Behavior)**:
  - For regular bugs: Look for traps like `int3` (x64), `brk #0` (arm64), or
    calls to the Abort builtin / `v8::base::OS::Abort` in the backtrace or
    disassembly, or `"Fatal error"` / `"Safely terminating process"` in stderr.
  - For sandbox testing (`--sandbox-testing`): Look for
    `"V8 sandbox violation detected"` (write access outside the sandbox) vs.
    `"Caught harmless memory access violation"` (safe termination, read-only
    access, or guard-region hits).