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: An integer narrowing vulnerability in ICU’s BiDi implementation allows an attacker to trigger an undersized heap allocation by providing a large string of alternating LTR/RTL text. The calculation runCount * sizeof(Run) overflows when implicitly cast to a 32-bit integer, resulting in a subsequent 4.3 GB out-of-bounds write in the renderer process. While guard pages will eventually catch the write, an attacker could potentially exploit a race condition using Web Workers to access corrupted memory before the crash.

Affected files:

• third_party/icu/source/common/ubidiln.cpp
• third_party/icu/source/common/ubidiimp.h
• third_party/icu/source/common/ubidi.cpp
• third_party/blink/renderer/platform/text/bidi_paragraph.cc
• third_party/blink/renderer/core/layout/inline/inline_node.cc
• third_party/blink/renderer/platform/fonts/plain_text_node.cc

Estimated timestamp from git blame: 2014-03-26

Summary

A potential heap buffer overflow write vulnerability exists in the ICU library used by Chrome, specifically within the ubidi_getRuns function. The issue stems from an integer narrowing (truncation) from a 64-bit size_t to a 32-bit int32_t when calculating the memory required for BiDi runs. By providing a string with a large number of directionality transitions, an attacker can trigger an undersized allocation, leading to a massive out-of-bounds (OOB) write in the renderer process.

Root Cause Analysis

In third_party/icu/source/common/ubidiimp.h, the getRunsMemory macro calculates the byte size for an array of Run structures:

#define getRunsMemory(pBiDi, length) \
        ubidi_getMemory((BidiMemoryForAllocation *)&(pBiDi)->runsMemory, &(pBiDi)->runsSize, \
                        (pBiDi)->mayAllocateRuns, (length)*sizeof(Run))

The Run struct is 12 bytes. The length parameter is an int32_t representing the runCount. Because sizeof(Run) evaluates to a size_t (a 64-bit unsigned integer on 64-bit platforms), the multiplication (length)*sizeof(Run) is promoted to a 64-bit size_t.

However, the result is passed to ubidi_getMemory (defined in third_party/icu/source/common/ubidi.cpp), where the sizeNeeded parameter is defined as a 32-bit int32_t:

U_CFUNC UBool
ubidi_getMemory(BidiMemoryForAllocation *bidiMem, int32_t *pSize, UBool mayAllocate, int32_t sizeNeeded) {
    // ...
    if(mayAllocate && (*pMemory=uprv_malloc(sizeNeeded))!=nullptr) {
    // ...

If an attacker crafts a string that generates exactly 357,913,942 runs, the calculation is 357,913,942 * 12 = 4,294,967,304 (0x100000008 in hex). When passed into ubidi_getMemory, this value is implicitly narrowed to a 32-bit int32_t, truncating the top bits and resulting in a sizeNeeded of exactly 8.

ICU’s BUILD.gn explicitly sets -Wno-conversion, meaning the compiler does not emit warnings for this truncation. uprv_malloc(8) succeeds, and the subsequent logic in ubidiln.cpp incorrectly assumes it has memory for 357 million runs.

OOB Write Loop

The vulnerability is exploited in third_party/icu/source/common/ubidiln.cpp within the ubidi_getRuns function. After the undersized 8-byte allocation, the following loop executes:

do {
    // ...
    runs[runIndex].logicalStart=start;
    runs[runIndex].visualLimit=i-start;
    runs[runIndex].insertRemove=0;
    ++runIndex;
} while(i<limit);

This loop writes 12 bytes per iteration for 357,913,942 iterations, resulting in a linear OOB write of approximately 4.3 GB past the end of the 8-byte allocation.

Suggested Attack Steps

Note: These steps are theoretical as our tooling cannot currently execute code to verify the exploit chain.

1. Craft the String: The attacker uses JavaScript to allocate a text string of precisely 357,913,942 characters. The string is designed to alternate between strong Left-to-Right (e.g., ‘A’) and strong Right-to-Left (e.g., ‘א’) characters ("AאAאAא..."). This forces the Unicode Bidirectional Algorithm to create a new run for every single character.
2. Validate Limits: This string consumes ~716 MB of RAM (UTF-16), which is well within V8’s kMaxLength limit for 64-bit systems (~536.8M characters) and the renderer process memory limits.
3. Trigger BiDi Resolution: The attacker forces Blink to process the bidirectional text, for example by invoking CanvasRenderingContext2D.measureText() with the string, or inserting it into the DOM for layout.
4. Race Condition: The OOB write is massive (4.3 GB) and linear. It will inevitably cross a 2 MiB SuperPage boundary and hit a PartitionAlloc guard page, causing a deterministic unhandled access violation (segfault). However, an attacker can tune the string length (e.g., to 357,913,944 runs) to target a specific PartitionAlloc bucket. While the main thread is sequentially overwriting adjacent objects within that bucket’s slot span, a concurrent Web Worker thread (which shares the PartitionAlloc main partition) could allocate and interact with objects in that same bucket. If the Worker accesses a partially corrupted object before the main thread hits the guard page, it could achieve a Use-After-Free or Type Confusion primitive.

Suggested Fix

The immediate fix is to add overflow checks or use safe integer math when calculating allocation sizes in ICU.

In third_party/icu/source/common/ubidiimp.h, modify the memory allocation macros to check for size_t to int32_t overflow:

// Example using Chromium's base::CheckedNumeric or similar safe math
// Alternatively, fail the allocation if (length) > INT32_MAX / sizeof(Run)

Ideally, ubidi_getMemory and related ICU memory functions should be updated to use size_t for sizeNeeded rather than int32_t to align with modern C/C++ memory management practices.

Evaluated with Chrome root at commit: 7353d249d9cacf9c7218e1d7b8a39cf39c72d646

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.