---
name: v8-poc-classification
description: Checks if a POC provided by some JS and d8 flags is a vulnerability or just a regular bug.
---

# 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. If your analysis shows it is a `DCHECK` failure or
  relies on experimental flags, classify it as a **Bug**.

## 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).
- **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. 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**:
  - **Status**: Reproduced / Not Reproduced.
  - **Reproduction**: `d8 <flags> <poc.js>` (Exact command used locally).
  - **Result**: Summarize the result of running the command (output, crash,
    sandbox violation, harmless memory access).
  - **Build**: The build variant (e.g., x64.release, x64.debug, asan). Always
    include the V8 version from `src/utils/version.h` and the specific git hash
    using `git rev-parse HEAD` for technical accuracy.
  - **Verified Impact**: Summarize the **Verified Impact** (e.g., confirmed OOB
    write). If the bug is purely logical and caught by runtime protections (like
    `ref.cast` or bounds checks) without crashing, state this clearly.
  - **GDB Backtrace**: Include a snippet if it supports the classification.

Summary of rules from [triaging.md](../../../docs/security/triaging.md) based on
the threat model:

#### Regular Bugs (No initial in-sandbox write)

- **Type=Vulnerability**: Production code, enabled by default, survives the
  security POC flags (`--run-as-security-poc`).
- **Type=Bug**: Requires experimental flags (not in `--future`), developer
  flags, or only triggers a `DCHECK` or reliable `CHECK` (safe termination).
- **Intended Behavior**: Safe termination (e.g., via `SBXCHECK`, `FATAL`, or
  hardened libc++ checks).
  - **Indicators:** Look for traps like `int3` (x64), `brk #0` (arm64), or calls
    to the Abort builtin or the runtime function in the backtrace/disassembly.
    Also look for "Fatal error" or "Safely terminating process" in stderr, or
    calls to `v8::base::OS::Abort` in the backtrace.

#### Sandbox Bypasses (Starts with in-sandbox write/corruption)

- **Type=Vulnerability**: Demonstration of **write access** outside the sandbox
  (e.g., "V8 sandbox violation detected") using `--sandbox-testing`.
- **Intended Behavior**: Read-only bypass, or safe termination ("Caught harmless
  memory access violation"). Includes linear OOB writes (e.g., `memset`,
  `memcpy`) hitting guard regions, or corrupting trusted objects with
  well-formed data of the same type. Also includes breaking internal invariants
  using testing-only natives (restricted by `IsEnabledForFuzzing`) if the impact
  is safely contained.