Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A memory ordering race on weak memory architectures (like ARM64) between mutator allocations and the concurrent marker leads to an integer underflow in ObjectStartBitmap::FindHeader. This returns an out-of-bounds pointer into an adjacent heap page, causing the marker to trace forged headers and internal page structures, leading to arbitrary code execution.

Affected files:

• v8/src/heap/cppgc/object-start-bitmap.h
• v8/src/heap/cppgc/member-storage.h
• v8/src/heap/cppgc/concurrent-marker.cc
• v8/src/heap/cppgc/heap-page.h
• v8/src/heap/cppgc/trace-trait.cc
• v8/src/heap/cppgc/marking-state.h

Estimated timestamp from git blame: 2023-02-27

Summary

A vulnerability exists in V8’s cppgc (Oilpan) garbage collector. On weak memory architectures like ARM64, a memory ordering race can occur when assigning a newly allocated object to a cppgc::Member. The concurrent marker can observe the new pointer before the corresponding bit is set in the ObjectStartBitmap. This stale state triggers an integer underflow in ObjectStartBitmap::FindHeader, resulting in an out-of-bounds pointer. Because cppgc pages lack guard pages, this pointer resolves to the payload of the adjacent preceding page, allowing an attacker to forge a HeapObjectHeader, force type confusion on internal heap metadata, and achieve arbitrary code execution in the renderer process.

Technical Details

1. The Memory Ordering Race

When a mutator thread allocates a new object on a fresh page, it registers the object’s start address in the page’s bitmap. This is done via ObjectStartBitmap::SetBit<AccessMode::kAtomic>, which performs a std::memory_order_release store.

Subsequently, if this new pointer is assigned to a cppgc::Member of an object currently being traced, the pointer is written using std::memory_order_relaxed (v8/include/cppgc/internal/member-storage.h:102). The assignment triggers a write barrier, but the fast path only performs relaxed checks and does not emit a strong memory fence (like memory_order_seq_cst).

On ARM64, a Store-Release prevents prior operations from being reordered after it, but it does not prevent subsequent operations from being reordered before it. Consequently, the relaxed store of the Member pointer can become globally visible before the release store to the bitmap.

2. The Integer Underflow

The concurrent marker background thread, reading the Member via an acquire/relaxed load, observes the new pointer but not the updated bitmap. To trace the object (specifically a mixin), it calls ObjectStartBitmap::FindHeader to locate the HeapObjectHeader.

FindHeader scans the bitmap backwards to find the nearest set bit. Because the page is fresh and the mutator’s bit isn’t visible, every cell is 0. The loop (while (!byte && cell_index) { byte = load<mode>(--cell_index); }) decrements cell_index until it reaches 0.

The function then executes:

const int leading_zeroes = v8::base::bits::CountLeadingZeros(byte);
object_start_number = (cell_index * kBitsPerCell) + (kBitsPerCell - 1) - leading_zeroes;

Passing 0 to CountLeadingZeros returns 8 (v8/src/base/bits.h). Substituting the values yields (0 * 8) + 7 - 8 = -1. Because object_start_number is a size_t, -1 underflows to SIZE_MAX.

The code then calculates object_offset = object_start_number * kAllocationGranularity (where granularity is 8). Due to two’s complement arithmetic, SIZE_MAX * 8 results in -8. FindHeader returns page_base - 8.

3. Heap Adjacency and Exploitation

In cppgc, NormalPage allocations are 128KB contiguous blocks within the Caged Heap, with no implicit guard pages between them (v8/src/heap/cppgc/page-memory.cc). The payload of a NormalPage can extend precisely to the 128KB boundary. Therefore, page_base - 8 points to the last 8 bytes of the payload of the immediately preceding page (Page A).

An attacker can reliably trigger this condition by:

1. Grooming the heap to control the last 8 bytes of Page A.
2. Forging a HeapObjectHeader in those 8 bytes, setting the 14-bit GCInfoIndex (offset +4 on 64-bit) to correspond to a useful Trace callback, and leaving the mark bit (offset +6) as 0.
3. Allocating a new mixin object on Page B (triggering the race).

When FindHeader returns page_base - 8, the marker casts it to a HeapObjectHeader and reads the attacker’s forged GCInfoIndex. It then performs an atomic CAS to flip the mark bit at page_base - 2, which succeeds.

Finally, the marker calculates the payload pointer by adding sizeof(HeapObjectHeader) (8 bytes) to the returned pointer: (page_base - 8) + 8 = page_base. It then invokes the attacker’s chosen Trace function on this pointer.

Because page_base is exactly offset 0 of Page B, it points to the NormalPage struct itself. The Trace function interprets the internal V8 heap metadata (such as Space*, SlotSet*, and the massive ObjectStartBitmap array) as user-defined pointers. This massive type confusion allows the attacker to corrupt Oilpan’s internal state, achieve arbitrary out-of-bounds writes during the sweep phase, and ultimately execute arbitrary code within the renderer process.

Suggested Fix

There are two primary ways to fix this vulnerability:

1. Fix the Math: Modify ObjectStartBitmap::FindHeader to safely handle the case where the bitmap is entirely zero. If byte == 0 after the loop, the function should explicitly crash (CHECK(false)) or return nullptr instead of relying on the underflowing arithmetic.
2. Memory Ordering: Ensure that the write barrier for cppgc::Member assignment enforces sequential consistency or proper acquire-release semantics to prevent the relaxed pointer store from being reordered before the ObjectStartBitmap update.

Evaluated with Chrome root at commit: eca8648a4e1cdfdda68c495a6003059fed641955

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.