Report description

WebNN ScatterND integer overflow in TFLite bounds check allows for 512MB controlled heap OOB write

Bug location

Where do you want to report your vulnerability?

Chrome VRP – Report security issues affecting the Chrome browser. See program rules

Which URL (or repository) have you found the vulnerability in?

https://chromium.googlesource.com/chromium/src/+/main/services/webnn/tflite/graph_builder_tflite.cc

The problem

Please describe the technical details of the vulnerability

Vulnerability Details

SerializeScatterND (graph_builder_tflite.cc:7879) passes runtime indices directly to TFLite with no bounds validation. The other scatter/gather ops either clamp (Gather, GatherND via SerializeGatherIndices) or reject runtime indices entirely (GatherElements, ScatterElements — constant-only).

TFLite’s bounds check in reference_ops::ScatterNd (third_party/tflite/src/tensorflow/lite/kernels/internal/reference/reference_ops.h) has an int32 overflow:

if (to_pos < 0 || to_pos + slice_size > output_flat_size) {
    return kTfLiteError;
}

With shape=[3, 536870912] int8 and index 3:

• to_pos = 1,610,612,736
• to_pos + slice_size = 2,147,483,648 → wraps to -2,147,483,648
• -2,147,483,648 > 1,610,612,736 → false → bypassed

Result: 536,870,912 bytes of attacker-controlled data written past the buffer end. The attacker controls the write content via the updates tensor.

The write occurs in the GPU process.

Bisect: Introduced in b4d4b4cb019bd7240a52daa4ba61e3cc814f0384 (fix for CVE-2022-35939, TF 2.10.0).

Suggested fix:

if (to_pos < 0 || static_cast<int64_t>(to_pos) + slice_size > output_flat_size) {

Version

Chrome: 144.0.7559.110 (Stable), 146.0.7655.0 (Dev)

OS: macOS 15.7.2, Windows 11. Cross-platform.

Flags: --enable-features=WebMachineLearningNeuralNetwork --in-process-gpu WebNN is behind a flag (W3C spec implementation in progress). --in-process-gpu is for crash visibility only, the bug triggers without it.

Reproduction

1. Kill all Chrome instances, relaunch with flags above
2. Open scatternd_heap_oob.html, click “Trigger OOB Write”
3. Chrome crashes — EXC_BREAKPOINT / SIGTRAP (PartitionAlloc heap corruption)

Standalone proof (no browser):

clang++ -O2 -fno-strict-overflow -fsanitize=address -g -o bug370_asan bug370_asan_proof.cc
./bug370_asan

Symbolized stack trace (thread 0, main thread):

  #0  __pthread_kill + 10
  #1  pthread_kill + 259
  #2  abort + 126
  #3  __sanitizer::Abort() + 88
  #4  __sanitizer::Die() + 97
  #5  __asan::ScopedInErrorReport::~ScopedInErrorReport() + 1300
  #6  __asan::ReportGenericError() + 1782
  #7  __asan_report_load1 + 54
  #8  ScatterNd_vulnerable() at bug370_asan_proof.cc:98    ← OOB access detected here
  #9  test_overflow_exploit() at bug370_asan_proof.cc:191  [inline]
  #10 main() at bug370_asan_proof.cc:262
  #11 start + 3056

Attachments:

• scatternd_heap_oob.html — Browser PoC (59 lines)
• bug370_asan_proof.cc — Standalone proof, ASan heap-buffer-overflow
• crash_chrome_stable.ips — Stable 144 crash
• crash_report_chrome_dev.ips — Dev 146 crash
• crash_asan_standalone.ips — ASan crash with symbolication

Crash Details

Type: GPU process

Stable 144.0.7559.110 (2/2):

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Termination Reason: Trace/BPT trap: 5
Faulting Thread: ThreadPoolSingleThreadSharedForegroundBlocking4

Dev 146.0.7655.0 (5/5):

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Termination Reason: Trace/BPT trap: 5
Faulting Thread: ThreadPoolForegroundWorker

Both are PA_IMMEDIATE_CRASH() from PartitionAlloc detecting heap metadata corruption.

lldb on ASan Chromium , the PoC fills the updates tensor with 0x42. Breakpoint on EvalScatterNd<int>, int8 output tensor at 0x29E183840, size 0x60000000. After return, 0x42 appears at every OOB position:

(lldb) memory read -c 64 0x2FE183840
0x2fe183840: 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB
0x2fe183850: 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB
0x2fe183860: 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB
0x2fe183870: 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB

(lldb) memory read -c 16 0x30E183840    # +256MB
0x30e183840: 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42  BBBBBBBBBBBBBBBB

(lldb) memory read -c 16 0x31E183840    # +512MB (first byte past the write)
0x31e183840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

512MB of attacker-controlled 0x42 past the buffer boundary, stopping exactly at slice_size.

Note: ASan Chromium doesn’t flag the OOB because TFLite’s SimpleMemoryArena allocates a single contiguous buffer for all tensors (~6.4GB), and the OOB write stays within it. The standalone proof uses new[] with normal red zones, so ASan triggers immediately.

Impact analysis

Any website can trigger a 512MB attacker-controlled heap write in Chrome’s GPU process if the user has enabled the WebNN feature flag. The attacker controls the write content (via the updates tensor) and the write offset (via the indices tensor). No user interaction is required beyond navigating to the page. The GPU process runs with a weaker sandbox than the renderer and has IPC channels to the browser process, making this a potential stepping stone for sandbox escape.

The cause

What version of Chrome have you found the security issue in?

Stable, Dev

Is the security issue related to a crash?

Yes, it is related to a crash.

Choose the type of vulnerability

Memory Corruption (in a non-sandboxed process)

How would you like to be publicly acknowledged for your report?

cinzinga