Report description

V8 Sandbox Bypass: same-tag Managed<WasmStreaming> substitution races mutable StreamingDecoder::url_ after callback publication and causes a native heap UAF

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://source.chromium.org/chromium/chromium/src

The problem

Please describe the technical details of the vulnerability

Each WebAssembly.compileStreaming() call creates a distinct WasmStreaming, wraps its std::shared_ptr in Managed<WasmStreaming>, and installs that wrapper as the fulfillment and rejection callback data.

// v8/src/wasm/wasm-js.cc:838-854
std::shared_ptr<WasmStreaming> streaming = std::make_shared<WasmStreaming>(...);
i::DirectHandle<i::Managed<WasmStreaming>> data =
    i::Managed<WasmStreaming>::From(i_isolate, 0, streaming);
v8::Function::New(context, i_isolate->wasm_streaming_callback(),
                  Utils::ToLocal(i::Cast<i::Object>(data)), 1);

WasmStreaming::kManagedTag is exactly kWasmWasmStreamingTag, and WasmStreaming::Unpack() resolves callback data through Managed<WasmStreaming>::ptr(). That exact-tag lookup verifies the native resource type but cannot verify that the live WasmStreaming belongs to the Promise reaction carrying the callback data.

// v8/include/v8-wasm.h:164-168; v8/src/wasm/wasm-js.cc:166-173
static constexpr internal::ExternalPointerTag kManagedTag =
    internal::kWasmWasmStreamingTag;

std::shared_ptr<WasmStreaming> WasmStreaming::Unpack(Isolate* isolate,
                                                     Local<Value> value) {
  auto managed =
      i::Cast<i::Managed<WasmStreaming>>(Utils::OpenDirectHandle(*value));
  return managed->ptr().as_shared_ptr();
}

With arbitrary read/write access inside the V8 sandbox, the PoC copies request B’s genuine live external-pointer handle into the callback-data Foreign of another streaming request. The other request’s fulfillment callback consequently obtains B’s live WasmStreaming. The external-pointer entry, ManagedPtrDestructor, and WasmStreaming are all still valid.

Blink obtains the WasmStreaming from args.Data() but obtains the Response independently from args[0]. StreamFromResponseCallback() writes that response’s URL, optionally installs its code-caching callback, and only then starts body loading; it performs no request-identity check.

// third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc:493-498,528,600-625
std::shared_ptr<v8::WasmStreaming> streaming =
    v8::WasmStreaming::Unpack(args.GetIsolate(), args.Data());
Response* response = V8Response::ToWrappable(args.GetIsolate(), args[0]);
// ...
streaming->SetUrl(url_utf8.c_str(), url_utf8.size());
if (cache_handler) {
  streaming->SetMoreFunctionsCanBeSerializedCallback(...);
}
response->BodyBuffer()->StartLoading(...);

StreamingDecoder retains one mutable std::string. shared_url() shares that same object instead of taking an immutable value snapshot, while SetUrl() performs an unchecked std::string::assign() on it.

// v8/src/wasm/streaming-decoder.h:124-129,169-181
std::shared_ptr<const std::string> shared_url() const { return url_; }

void SetUrl(base::Vector<const char> url) {
  url_->assign(url.begin(), url.size());
}

StreamState stream_state_{kReceivingBytes};
const std::shared_ptr<std::string> url_ = std::make_shared<std::string>();

WasmStreamingImpl::SetMoreFunctionsCanBeSerializedCallback() captures this shared mutable string and later copies *url while a V8 compilation callback constructs CompiledWasmModule.

// v8/src/wasm/wasm-js.cc:98-105
streaming_decoder_->SetMoreFunctionsCanBeSerializedCallback(
    [callback = std::move(callback),
     url = streaming_decoder_->shared_url()](
        const std::shared_ptr<i::wasm::NativeModule>& native_module) {
      callback(CompiledWasmModule{native_module, *url});
    });

The API contract says SetUrl() must run before Finish(), but the implementation neither checks stream_state_ nor synchronizes with CompilationStateImpl::callbacks_mutex_. A substituted request can therefore call SetUrl() on an already-finished decoder while TriggerCodeCachingAfterTimeoutTask::Run() reaches CompilationStateImpl::TriggerCallbacks() and copies the same string on a V8 background thread.

The PoC uses already-aborted data-URL responses for these late URL changes. Blink executes SetUrl() first, then BodyStreamBuffer::StartLoading() observes the abort. Because normal completion already moved the decoder’s processors out, the subsequent StreamingDecoder::Abort() returns without delivering bytes to the finished stream or removing the callback already published to CompilationState.

The dangling pointer is produced in libc++’s long-string copy path. For the attached result, the first late assignment uses a 17,036,831-byte URL, producing a 17,036,832-byte allocation with public capacity 17,036,831. The background copy snapshots the old data pointer and length, then allocates its destination. Concurrently, a second late assignment uses a 17,036,832-byte URL, which is one byte beyond the old capacity; std::string::__grow_by_and_replace() allocates replacement storage and frees the old buffer. The pending __asan_memmove() then reads 17,036,832 bytes, including the terminator, through the dangling old pointer.

PoC

The attachments are poc.html, server.py, and asan.log. server.py embeds an unmodified XZ/base64 encoding of the published @ffmpeg/core 0.12.10 dist/umd/ffmpeg-core.wasm, obtained during packaging from https://cdn.jsdelivr.net/npm/@ ffmpeg/core@0.12.10/dist/umd/ffmpeg-core.wasm; the decoded bytes are 32,232,419 bytes with SHA-256 9f57947a5bd530d8f00c5b3f2cb2a3492faa7e5d823315342d6a8656d0a6b7b7. It verifies those bytes and serves only poc.html and /module.wasm from 127.0.0.1. This endpoint is required because FetchManager::Loader::DidReceiveResponse() creates ScriptCachedMetadataHandler for an HTTP-family application/wasm response (third_party/blink/renderer/core/fetch/fetch_manager.cc:723-741), and StreamFromResponseCallback() installs the V8 caching callback only when that handler exists (third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc:600-625). The PoC does not contact the packaging URL and uses no separate .wasm file.

The page creates finished victim streams, copies each victim’s genuine live kWasmWasmStreamingTag handle into pending compileStreaming() callback-data Foreign objects, and drives default tiering so late SetUrl() calls race the code-caching callback.

The frozen package reproduced the target UAF in 17 of 30 isolated launches of the official build (56.7%). A missed race normally closes the page; repeat the same Chrome command while leaving server.py running.

Reproduce

Confirmed in asan-v8-sandbox-testing-linux-release-1669311.zip.

In one terminal, start the fixed loopback endpoint:

python3 /path/to/server.py

After it prints the readiness line, run the official sandbox-testing ASan build in a second terminal:

/path/to/chrome \
  --headless=new \
  --incognito \
  '--js-flags=--run-as-sandbox-security-poc' \
  http://127.0.0.1:8181/poc.html

Impact analysis

An attacker with arbitrary read/write access inside the V8 sandbox can redirect an ordinary WebAssembly.compileStreaming() callback to another live exact-tag WasmStreaming and trigger a cross-thread heap UAF in native libc++ storage outside the sandbox.

The cause

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

153.0.7978.0

Is the security issue related to a crash?

Yes, it is related to a crash.

Choose the type of vulnerability

Sandbox Escape