Longinus: 2 Boundaries in One Bug, Piercing Chrome’s Renderer and V8 Sandbox with a Single Vulnerability, CVE-2026-6307

TurboFan

TurboFan is V8’s optimizing compiler. After a JavaScript function has run enough times, V8 can use feedback collected by the lower execution tiers to compile a specialized version of that function. This feedback includes information such as the shapes of objects, the targets seen at call sites, and the representations of values used by particular operations.

V8 initially executes a function through Ignition bytecode and may move it through other tiers before TurboFan compiles it. Those earlier executions populate the function’s feedback vector. TurboFan turns the bytecode and feedback into a compiler graph, applies high-level JavaScript optimizations, and eventually lowers the graph toward machine operations. Turboshaft is the lower-level compiler representation used during this pipeline and is where the value-numbering behavior relevant to this bug takes place.

At a high level, TurboFan’s job is to replace generic JavaScript execution with specialized machine code while preserving a way back to correct generic execution. It can inline callees, specialize property accesses, and emit checks that guard the assumptions it made from feedback. If one of those assumptions is invalidated later, optimized execution must deoptimize.

Sea of Nodes

TurboFan represents the function being compiled as a graph, often described as a Sea of Nodes. Instead of a simple linear instruction list, operations are connected by their dependencies. A node can depend on value inputs, control inputs, and effect inputs. This lets TurboFan move and simplify operations while still preserving the ordering required for side effects and control flow. In a traditional CFG, the compiler asks: Which basic block does this instruction belong to, and in what order does it run? But in Sea of Nodes, the compiler asks: What does this operation depend on, and where can it legally be placed later? That difference matters because Sea of Nodes avoids committing too early to an instruction’s exact location. For example:

1
function f(x, y, z) {
2
    let a = x + y;
3
    let b = y + z;
4

5
    if (a > 0)
6
        return b * 2;
7
    else
8
        return b * 3;
9
}

In a CFG, you might represent it as:

1
B1:
2
  a = x + y
3
  b = y + z
4
  if a > 0 goto B2 else B3
5

6
B2:
7
  return b * 2
8

9
B3:
10
  return b * 3

Here, b = y + z is already placed in block B1.

In Sea of Nodes, b = y + z is just an Add node depending on y and z:

1
y     z
2
 \   /
3
  Add(b)

It does not have to belong to a basic block immediately. Later, the compiler can decide whether to place it before the branch, inside one branch, hoist it, sink it, eliminate it, or share it with another identical computation. That is the key benefit: more optimization freedom. Sea of Nodes is especially good for: common subexpression elimination, global value numbering, dead code elimination, code motion, bounds-check elimination.

Finally, it schedules the Sea of Nodes graph into basic blocks, lowers nodes to machine instructions, assigns registers, removes things like Phi, then emits linear assembly/machine code.

For this bug, the important point is that calls, checks, and deoptimization metadata all live in the same graph. When TurboFan inlines a call, the callee’s operations are inserted into the caller’s graph. If the inlined operation can deoptimize, the graph also contains FrameState nodes describing how execution should be reconstructed if optimized execution cannot continue.

FrameState nodes are metadata, but they are still graph nodes with inputs and options. They do not execute like arithmetic or memory operations, yet optimization passes can still reason about them. Later in the writeup, this matters because two JS-to-Wasm continuation FrameState nodes can look equivalent to the graph optimizer even though they describe different Wasm return types.

JS-to-Wasm call inlining

One TurboFan optimization relevant to this bug is JS-to-Wasm call inlining. JavaScript and WebAssembly use different calling conventions and value representations, so a call from JavaScript into Wasm normally goes through a JS-to-Wasm wrapper. The wrapper converts JavaScript arguments to Wasm values, performs the Wasm call, and converts the Wasm result back to a JavaScript value.

TurboFan can inline that wrapper into the optimized JavaScript caller. This avoids a separate wrapper call and exposes the argument/result conversion code to the optimizer. V8 may also inline sufficiently small Wasm function bodies, but full Wasm-body inlining is not required for this bug. Inlining the wrapper is enough.

In this writeup, the JS-to-Wasm call is reached through a JavaScript property getter. After warmup, TurboFan can specialize the property access, check the receiver shape, call the known getter target directly, and inline the JS-to-Wasm wrapper for that target. If the same JavaScript function sees two receiver shapes, the optimized graph can contain two such getter paths in one compiled function.

Each inlined wrapper is built from the canonical signature of its Wasm function. Canonicalization lets V8 represent structurally equivalent function types with a shared signature object. The signature contains both parameter and return types; it is therefore more precise than simply recording how many values the continuation builtin receives.

Two return types matter for this bug. A Wasm i64 is exposed to JavaScript as a BigInt, while an externref is a tagged JavaScript reference.

For a Wasm function with this signature:

1
(func (result i64))

the machine return value is a raw 64-bit integer. The wrapper must turn that integer into a BigInt before returning to JavaScript. For this function:

1
(func (result externref))

the value in the return register is already a tagged reference and must be handled as such. The machine-level return location may be the same, but the meaning of the bits is determined by the Wasm signature.

The important detail is that the wrapper signature decides how the Wasm return bits are converted back to JavaScript.

Deoptimization

Deoptimization replaces an active optimized frame with one or more frames that can continue in a lower tier. To do this, V8 must recover the state that the unoptimized function expects: its parameters, local variables, context, current bytecode position, and any inlined frames.

Optimized code does not necessarily keep these values in their original form. A local might be stored in a register, folded into a constant, or removed entirely. The compiler therefore attaches deoptimization metadata to points where execution may leave optimized code. In TurboFan and Turboshaft, this state is represented using FrameState nodes.

A simplified FrameState contains:

• The values needed to rebuild the frame, such as parameters and locals.
• An outer FrameState when the current operation was inlined into another function.
• A FrameStateInfo describing the kind of frame, its continuation point, and function-specific metadata.

The compiler can nest these states. If a getter and its JS-to-Wasm wrapper have been inlined into the optimized caller, the inner continuation state points to the outer JavaScript state. The deoptimizer walks that chain to recreate the logical call stack even though those calls no longer exist as separate physical frames in the optimized machine code.

There are two relevant ways deoptimization can happen. An eager deoptimization occurs immediately when a check fails. At that point, all values required to reconstruct the frame are available at the deopt point. A lazy deoptimization is associated with a call. The optimized function can be marked for deoptimization while another function is running, but the transition only occurs when that call returns.

Lazy deoptimization needs special handling for the call result. The result does not exist when the FrameState is created, so it is not listed as a normal input. Instead, the deoptimizer obtains it from the machine return register and adds it to a continuation frame. Execution then resumes through a continuation builtin as if the optimized call had returned normally.

For a JS-to-Wasm call inlined by TurboFan, V8 creates an inner continuation FrameState with the type kJSToWasmBuiltinContinuation. Its function information uses a derived class that stores the Wasm signature:

1
class JSToWasmFrameStateFunctionInfo : public FrameStateFunctionInfo {
2
 public:
3
  const wasm::CanonicalSig* signature() const { return signature_; }
4

5
 private:
6
  const wasm::CanonicalSig* const signature_;
7
};

This signature is not just informational. During code generation, V8 derives the Wasm return kind from it and serializes that kind into the deoptimization data. If a lazy deoptimization occurs, the deoptimizer uses the recorded return kind to materialize the result.

Materializing Wasm return values

For JS-to-Wasm lazy deoptimization, the call has already returned at the machine-code level. The deoptimizer therefore reconstructs the call result from the return register and the recorded Wasm return kind:

1
TranslatedValue Deoptimizer::TranslatedValueForWasmReturnKind(
2
    std::optional<wasm::ValueKind> wasm_call_return_kind) {
3
  if (wasm_call_return_kind) {
4
    switch (wasm_call_return_kind.value()) {
5
      case wasm::kI32:
6
        return TranslatedValue::NewInt32(
7
            &translated_state_,
8
            static_cast<int32_t>(input_->GetRegister(kReturnRegister0.code())));
9
      case wasm::kI64:
10
        return TranslatedValue::NewInt64ToBigInt(
11
            &translated_state_,
12
            static_cast<int64_t>(input_->GetRegister(kReturnRegister0.code())));
13
      case wasm::kF32:
14
        return TranslatedValue::NewFloat(
15
            &translated_state_,
16
            input_->GetFloatRegister(wasm::kFpReturnRegisters[0].code()));
17
      case wasm::kF64:
18
        return TranslatedValue::NewDouble(
19
            &translated_state_,
20
            input_->GetDoubleRegister(wasm::kFpReturnRegisters[0].code()));
21
      case wasm::kRefNull:
22
      case wasm::kRef:
23
        return TranslatedValue::NewTagged(
24
            &translated_state_,
25
            Tagged<Object>(input_->GetRegister(kReturnRegister0.code())));
26
      default:
27
        UNREACHABLE();
28
    }
29
  }
30
  return TranslatedValue::NewTagged(&translated_state_,
31
                                    ReadOnlyRoots(isolate()).undefined_value());
32
}

The deoptimizer does not ask the original Wasm function what it returned; it trusts the wasm_call_return_kind serialized from the FrameState. For both kI64 and reference returns, it reads the same machine return register, kReturnRegister0. The only difference is how the bits are interpreted: kI64 casts the register value to an int64_t and boxes it as a BigInt, while kRef and kRefNull wrap the register value as a Tagged<Object>.

This is also why the externref case leaks a full 64-bit tagged value when confused with i64. Pointer compression affects many tagged values stored in heap fields, but Wasm reference values in the compiler graph use the tagged register representation. On pointer-compression builds, that register representation is a decompressed heap pointer, or a Smi. By the time the deoptimizer reads kReturnRegister0, there is no separate “32-bit compressed pointer plus cage base” pair to reconstruct; the register already contains the full tagged value.

Therefore, if the recorded return kind comes from the wrong FrameState, the deoptimizer directly reinterprets the same 64 bits as the wrong JavaScript value type. This is the point where an externref can be materialized as an i64, or an i64 can be materialized as an object reference.

FrameState merging

One subtle point is that FrameState nodes are still nodes in the compiler graph before they are serialized into deoptimization data. This means graph optimizations can also see them. The relevant optimization here is common subexpression elimination, also called global value numbering.

Common subexpression elimination is not part of the deoptimizer itself, but it can affect the metadata that the deoptimizer later consumes. If two graph nodes have the same inputs and equivalent metadata, the compiler can keep the first node and replace uses of the second with it. For normal operations, this removes redundant work. For FrameState nodes, it means two deoptimization states can be merged.

Merging two FrameState nodes is safe only when the states are interchangeable for deoptimization. Turboshaft first uses a quick hash to locate possible matches and then uses equality operators for the full comparison. That comparison must include every field that changes how a frame is reconstructed.

The FrameState hash intentionally uses only a small part of the metadata, including its bailout ID. Hash collisions are expected and are not themselves a bug: after finding a candidate with the same hash, value numbering compares the operation’s inputs and full options. The correctness boundary is therefore the equality comparison. If it says that semantically different deoptimization states are equal, one can be replaced with the other.

V8 Heap Sandbox

V8 Heap Sandbox is an in-process software fault isolation, that confines memory corruption bugs originating from untrusted JavaScript or WebAssembly code, limiting the effect in a subset of the process virtual address space region, or, the V8 heap sandbox region. The V8 heap sandbox assumes that an attacker can arbitrarily and concurrently read and write memory in the V8 heap sandbox region with primitives from typical traditional V8 vulnerabilities (addrof and fakeobj).

Without loss of generality, the implementation of the V8 heap sandbox can be regarded as adding an extra layer of translation to addressing operations.

The V8 sandbox is currently a 1 TB large region, containing all V8 heaps (located inside the 4GB V8 pointer compression cage at the start of the sandbox), ArrayBuffer backing stores and Wasm backing buffers. The address ing operation in V8 heap sandbox can be described as follows:

• Compressed pointer: 32-bit pointer, which is the pointer representation used in V8 heap sandbox. The compressed pointer cage is allocated at the start of the V8 heap sandbox region. When dereferencing a compressed pointer, the engine adds the base of the compressed pointer cage to the compressed pointer to get the actual address in the V8 heap sandbox region.
• Sandboxed pointer: objects located inside the sandbox can be referenced with a 40-bit offset from the base of the sandbox.
• Pointer Tables: V8 needs objects outside of the sandbox. These objects are referenced with Pointer Tables, which are also located outside of the sandbox, including CodePointerTable, TrustedPointerTable, and ExternalPointerTable. The pointer tables are used to store the actual addresses of objects outside of the sandbox with inlined type tag. Out-of-bounds access in those tables are also prevented, by reserving a fixed-size virtual memory block for every table during initialization and using left-shifted indices.

Finally, we can summarize the V8 heap sandbox as follows: