Security Bug

Important: Please do not change the component of this bug manually.

VULNERABILITY DETAILS

Title: [V8] Incomplete fix for CVE-2026-11075: TurboFan multi-add AdditiveSafeInteger truncation creates an out-of-bounds mutable SlicedString

The fix for CVE-2026-11075 restricts AdditiveSafeInteger feedback operands to approximately +/-2^51 so that adding two accepted operands remains within JavaScript’s safe-integer range. A longer truncatable addition chain can still propagate CheckedSafeIntTruncatingWord32 through several intermediate additions. Every leaf passes the post-fix feedback checks, but an intermediate JavaScript Number crosses 2^53 and rounds. TurboFan’s Word32 computation then differs from JavaScript Number semantics.

I use the incorrect result in a substring index calculation. Optimized code creates a 32,768-character SlicedString at the end of a 98,303-character source. The slice extends beyond its source and aliases a neighboring FixedDoubleArray. Ordinary JavaScript writes to that array subsequently change the contents of the supposedly immutable string after V8 has hashed and used it as a property key.

The attached poc.html is self-contained, uses no external resources, contains no personal information, and requires neither V8 native syntax nor --js-flags. It changes one string object’s contents from:

[97,113,119,115,101,100,114,102,116,103,121,104,117]

to:

[112,108,109,111,107,110,105,106,98,117,104,121,103]

using ordinary writes to the aliased FixedDoubleArray. It then shows the resulting property-key invariant violation: one object contains two distinct own keys whose current character contents are identical.

On success, the page title is PASS and the console result contains:

"ownCount":2
"sameContent":true
"sameIdentity":false

Root-cause lineage:

This report is not claiming AdditiveSafeInteger as a new class. It is a potentially new incomplete-fix variant of CVE-2026-11075, pending Chrome’s private duplicate check. The affected V8 revision already contains:

• 330a25ad001ee1ac3b7a2176a1f175cee2592a5f ([turbofan] Fix and simplify additive safe integer optimization, issue 499659070 / CVE-2026-11075)
• 289f555107da890a67a21f0826dbd5e71095c0ce (the follow-up retaining the Word32-truncated path used here)

The exact five-term post-fix trigger and mutable OOB SlicedString reproduce on the affected stable Chrome build and on locally built V8 main 5177b10891e65108c1a19dfc56bff4e58d79d216.

Security impact:

The primitive exposes attacker-controlled heap bytes through a V8 string and allows mutation after hashing, violating assumptions made by property tables, regular expressions, Script source, and other string consumers.

I also confirmed a controlled forward out-of-bounds write through Uri::Unescape: its first pass can count %41 triplets and allocate a small destination, while allocation/GC changes the physical OOB backing seen by the second pass. The second pass then emits more bytes than were counted without a release check of dest_position against the destination length. I can provide that deterministic diagnostic and the full source-level analysis if needed; the attached stock-Chrome PoC is intentionally limited to the smallest demonstration of the root bug.

Suggested remediation:

Do not retain CheckedSafeIntTruncatingWord32 through arbitrary addition chains based only on per-leaf feedback bounds. Prove the safe-integer range of every intermediate result, or deopt/use non-truncating Number semantics. Regression tests should cover three or more same-sign terms followed by cancellation after an intermediate result crosses 2^53.

VERSION

Chrome Version: 150.0.7871.46 stable, Chrome for Testing, Linux x86-64

Chromium tag: 5b586c06e0d27582900f17e2d59c5370d8d6e0bb

DEPS-pinned V8: 968f19a8970f8d91702d86f0ec1522f3909781b7 (V8 15.0.245.13)

Chrome binary SHA-256: 8c60a3ce09ad007490a232bb8a7243e60ec74d40d8d078b2648200b1c4f7f923

Operating System: Kali GNU/Linux Rolling 2024.3, x86-64, under WSL2 kernel 5.15.153.1-microsoft-standard-WSL2.

REPRODUCTION CASE

Attached poc.html directly to this report.

1. Open poc.html in Chrome 150.0.7871.46 using a fresh profile.

2. Allow approximately two seconds.

3. Observe page title PASS.

4. The console logs JSON containing:

   "ownCount":2
   "sameContent":true
   "sameIdentity":false
   

Exact headless command used for validation:

profile="$(mktemp -d)"
/path/to/chrome-150.0.7871.46/chrome-linux64/chrome \
  --headless=new --no-sandbox \
  --disable-crashpad --disable-breakpad --disable-crash-reporter \
  --enable-logging=stderr --user-data-dir="$profile" \
  "file://$PWD/poc.html"

--no-sandbox was used only because the validation process ran as root. It is not needed to trigger the V8 bug. No --js-flags are used.

The PoC succeeded in 10/10 fresh-profile runs on the affected binary.

Attachment:

poc.html

Size: 2,959 bytes

SHA-256: cb18bd99c80a5bea3f808699a3918a288b94ef01ce74804206e36218e929eec7

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION

CREDIT INFORMATION

Reporter credit: Raghav Maheshwari [[email protected]]

Additional submission note: I intend to use this initial-corruption bug for a v8CTF 0-day submission. v8CTF requires reporting it to Chrome VRP before capturing the flag, so this Chrome security report is being filed first. I will use the same reporter email address for the later v8CTF submission.