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.

Overview: An integer overflow in CalculationValueHandleMap allows a handle index to reach -1, which silently collides with the internal DeletedValue sentinel of the underlying WTF::HashMap. During table rehashing, this handle is dropped, leaving orphaned CSS Length objects. When these objects are destroyed, a failed map lookup returns map_.end(), causing an out-of-bounds decrement that perfectly aligns with the vtable pointer of adjacent polymorphic Oilpan objects.

Affected files:

• third_party/blink/renderer/platform/geometry/length.cc
• third_party/blink/renderer/platform/geometry/length.h

Estimated timestamp from git blame: 2025-05-28

Background and Root Cause

The CalculationValueHandleMap class (in third_party/blink/renderer/platform/geometry/length.cc) manages unique integer handles for CalculationValue objects used by CSS calc() expressions. It assigns handles using a monotonically increasing 32-bit signed integer, index_.

  int insert(const CalculationValue* calc_value) {
    DCHECK(index_);
    while (map_.Contains(index_))
      index_++;
    map_.Set(index_, MemberWithCount(calc_value, 1u));
    return index_;
  }

While handles can be freed, index_ is never reset. After approximately 2.14 billion insertions, index_ overflows INT_MAX. Because Chromium builds use -fno-strict-overflow (defining signed integer overflow to wrap), index_ continues incrementing from INT_MIN up to -1.

Sentinel Collision and Rehash Drop

The handles are stored in a WTF::HeapHashMap<int, MemberWithCount>. For integer keys, WTF::IntHashTraits<int> reserves -1 as the DeletedValue() sentinel.

When index_ reaches -1, map_.Set(-1, ...) successfully inserts the key into an empty bucket. In release builds, DCHECK macros are compiled out, so no fatal validation prevents this insertion. However, the hash table’s internal state is now corrupted: IsDeletedBucket(*entry) evaluates to true for the -1 bucket, even though it is active.

If the hash table subsequently expands, HashTable::RehashTo() iterates over the array to copy elements. It uses the condition if (IsEmptyOrDeletedBucket(table_[i])) continue;. Because the -1 key matches the deleted sentinel, the bucket is skipped and permanently dropped, leaving the associated CSS Length object holding an orphaned handle.

Out-of-bounds Dereference and RCE Primitive

When the DOM element owning the orphaned Length object is removed, the Length destructor calls CalcHandles().DecrementCount(-1).

  void DecrementCount(int index) {
    DCHECK(map_.Contains(index)); // Omitted in release builds
    auto iter = map_.find(index);
    --iter->value.count;
    // ...
  }

Because the bucket was dropped during the rehash, map_.find(-1) fails and returns map_.end(). In release builds, operator-> on WTF::HashTable iterators lacks bounds checks. The code unconditionally executes --iter->value.count, resulting in an out-of-bounds memory write.

Perfect Memory Alignment for VTable Corruption

The backing store of the hash table is allocated on the Blink GC (Oilpan) heap.

1. The KeyValuePair<int, MemberWithCount> struct is exactly 12 bytes long (4-byte int key, 4-byte Member compressed pointer, 4-byte unsigned count).
2. If the hash table has a capacity (table_size_) of 8, the payload is 96 bytes.
3. Oilpan objects on 64-bit platforms have an 8-byte HeapObjectHeader. The total allocation is 8 + 96 = 104 bytes.
4. Oilpan allocation granularity is 8 bytes. Since 104 is a multiple of 8, there is zero padding at the end of the allocation.
5. The end() iterator points to table_ + table_size_, which is exactly offset 104—the start of the next object’s HeapObjectHeader.
6. The decrement targets value.count, located at offset +8 relative to the iterator. Therefore, the memory accessed is offset 104 + 8 = 112 from the start of the first allocation.
7. Offset 112 bypasses the adjacent object’s header and points exactly to the first 8 bytes of the adjacent object’s payload.

For polymorphic C++ objects (e.g., ScriptWrappable DOM nodes), the first 8 bytes of the payload hold the vtable pointer. The -- operation deterministically decrements the adjacent object’s vtable pointer. By shaping the heap to place a controlled DOM node adjacent to the hash table, an attacker can hijack control flow upon the next virtual method call, leading to Remote Code Execution (RCE) in the renderer process.

Potential Attacker Steps to Trigger (Theoretical)

(Note: These are suggested steps; a working Proof of Concept has not yet been executed by our tooling.)

1. Execute a JavaScript loop that rapidly creates and deletes unresolvable calc() expressions (e.g., element.style.width = "calc(" + i + "% + 1px)"). This advances the index_ counter without exhausting memory.
2. Stop deleting elements when index_ approaches -1.
3. Insert the -1 handle.
4. Create a sufficient number of new calc() elements to exceed the load factor of the CalculationValueHandleMap, forcing a rehash that silently drops the -1 bucket.
5. Perform heap feng-shui to allocate a target polymorphic object (e.g., a specific DOM node) immediately following the current HashTable backing store.
6. Remove the DOM element associated with the -1 handle, triggering the out-of-bounds --iter->value.count on the adjacent vtable pointer.
7. Call a virtual method on the adjacent object to hijack execution flow to attacker-controlled memory.

Suggested Fix

To remediate this issue, CalculationValueHandleMap::insert must prevent the use of reserved sentinel values (specifically 0 and -1).

The while loop should be updated to skip negative values and zero:

  int insert(const CalculationValue* calc_value) {
    while (index_ <= 0 || map_.Contains(index_)) {
      index_++;
      if (index_ <= 0) {
        index_ = 1;
      }
    }
    map_.Set(index_, MemberWithCount(calc_value, 1u));
    return index_;
  }

Alternatively, consider migrating the map’s key to a robust 64-bit ID generator (like base::IdType or a uint64_t sequence) to entirely preclude overflow conditions within a realistic timeframe.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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.