CVE-2026-110153
Overview
Files Changed
third_party/blink/renderer/platform/media/multi_buffer_data_source.cc
Patch
From 8f54d92feff3932ab984565b6e71a356d0590797 Mon Sep 17 00:00:00 2001
From: Ted Meyer <tmathmeyer@chromium.org>
Date: Mon, 28 Sep 2026 14:29:50 -0700
Subject: [PATCH] [MultiBuffer] always post StopLoader
Stop can be called re-entrantly, from places which make use of weak
references to `reader_`, so we need to post the destruction back onto
this same task queue.
Fixed: 565742182
Change-Id: Ibaac92b7e77718379e5679fba3d37428d93f03b3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8465025
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Auto-Submit: Ted (Chromium) Meyer <tmathmeyer@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1706435}
---
diff --git a/third_party/blink/renderer/platform/media/multi_buffer_data_source.cc b/third_party/blink/renderer/platform/media/multi_buffer_data_source.cc
index 28a0d9a..5d2150e 100644
--- a/third_party/blink/renderer/platform/media/multi_buffer_data_source.cc
+++ b/third_party/blink/renderer/platform/media/multi_buffer_data_source.cc
@@ -333,13 +333,6 @@
{
base::AutoLock auto_lock(lock_);
StopInternal_Locked();
-
- // Cleanup resources immediately if we're already on the right thread.
- if (render_task_runner_->BelongsToCurrentThread()) {
- reader_.reset();
- url_data_.reset();
- return;
- }
}
PostCrossThreadTask(*render_task_runner_, FROM_HERE,
Original Bug Report
Heap-use-after-free in MultiBuffer::NotifyAvailableRange
Summary
MultiBuffer::NotifyAvailableRange() copies the readers of a block range into a local std::set<Reader*> and calls each one. One call can start a new fetch whose Oilpan allocation runs a garbage collection; HTMLMediaElement prefinalizers then destroy the MultiBufferReaders of other unreferenced media elements, and the loop calls them. Renderer, zero interaction.
Environment
- Chrome for Testing 154.0.8037.57 (Stable), 155.0.8059.12 (Beta), 156.0.8072.0 (Canary); code unchanged on main b7c07f35773a
- Ubuntu 24.04, x86-64
- Evidence build: ASan, Chromium 155.0.8038.0
Reproduction
python3 poc.py 8000
chrome --user-data-dir=/tmp/profile --no-first-run http://127.0.0.1:8000/poc.html
- Start
poc.py: it serves the page and a 32 MiB WAV with Range support, and controls when media bytes arrive (a static server does not reproduce). - Launch Chrome with a fresh profile. Zero interaction beyond loading the page; the renderer crashes after about 5 s.
Rate: Stable 3/3, Beta 2/2, Canary 5/5. The page reserves about 16 GB of address space (64-bit only).
Evidence
Renderer, main thread. Full report: asan.txt.
heap-use-after-free READ of size 8, 0 bytes inside 144-byte region
#0 MultiBuffer::NotifyAvailableRange multi_buffer.cc:278
freed: MultiBufferDataSource::Stop <- WebMediaPlayerImpl::Shutdown
<- HTMLMediaElement::InvokePreFinalizer <- (GC) <- ResourceMultiBufferDataProvider::Start
<- MultiBuffer::AddReader <- MultiBuffer::NotifyAvailableRange :278 (same loop)
MiraclePtr Status: NOT PROTECTED
Vulnerable code
third_party/blink/renderer/platform/media/multi_buffer.cc
272 std::set<Reader*> tmp; [1]
277 for (Reader* reader : tmp) {
278 reader->NotifyAvailableRange(new_range); [2]
[1] Plain pointers to every reader in the range. [2] A call can trigger a GC that deletes other readers still in tmp.
A separate report covers a related but distinct use-after-free in ResourceMultiBufferDataProvider::Start (different freed object and use site).
Impact
A web page with its own media server, no interaction. Renderer use-after-free. Reporter’s estimate: High (S1).
Discovery and validation
Found by AI-assisted source review and dynamic testing (Claude).
Attachments: poc.py, asan.txt, report.md (full write-up)