New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 472614 link

Starred by 0 users

Issue metadata

Status: Fixed
Closed: Apr 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

Heap-use-after-free in content::IndexedDBBackingStore::Transaction::ChainedBlobWriterImpl::ReportW

Project Member Reported by ClusterFuzz, Apr 1 2015

Issue description

Detailed report:

Fuzzer: Therealholden_worker
Job Type: Windows_asan_chrome

Crash Type: Heap-use-after-free READ 4
Crash Address: 0x03f7de80
Crash State:

Unminimized Testcase:

Additional requirements: Requires HTTP

Filer: inferno
Labels: Cr-Blink-Storage-IndexedDB
Status: Assigned
Project Member

Comment 2 by ClusterFuzz, Apr 1 2015

Labels: Pri-1
Labels: Security_Impact-Stable
Given the age of the code in question I'm going to assume it impacts stable. Please change if determined otherwise.
Passing it off to cmumford, but I'll take a quick look.
From a first glance, looks like the ChainedBlobWriterImpl's Abort() should be checking aborted_ - it looks plausible that during backing store close the transaction would be aborted and call Abort() on the writer. Later, the posted task still runs, and the writer's raw pointer to the backing store is derefed -> boom.
Project Member

Comment 6 by ClusterFuzz, Apr 1 2015

Labels: M-41
Status: Started
jsbell: I don't see how checking aborted_ (and doing an early return?) would fix this. Do you think it's possible for WriteBlobFile to result in Abort being called before it can set waiting_for_callback_ to true?
The "free" stack shows that the backing store has been closed. That would cause the transactions to all be aborted, which would Abort() their blob writers. I confess I didn't dig through the entire state machine of the writer to see what would happen next; I was guessing that if they had outstanding tasks (i.e. from the constructor?) it would fall into the bad path.

Project Member

Comment 10 by ClusterFuzz, Apr 3 2015

Labels: -M-41 M-42
Project Member

Comment 11 by ClusterFuzz, Apr 18 2015

Labels: Nag
cmumford@: Uh oh! This issue is still open and hasn't been updated in the last 14 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz
Not able to reproduce, but I did put up a change ( which is a (very) speculative fix for this.
Project Member

Comment 13 by, Apr 23 2015

The following revision refers to this bug:

commit 29777a8ee0f45b8160ec004e74013d5b62b6828a
Author: cmumford <>
Date: Thu Apr 23 18:56:12 2015

IndexedDB: Protect against use-after-free in ChainedBlobWriter.

This is a speculative fix for a heap user-after-free bug. Was unable
to verify using a Windows SyzyASan build. The theory is that if Abort()
was called before ChainedBlobWriterImpl::WriteNextFile() could set
waiting_for_callback_ then the ReportWriteCompletion() would never know
that it was aborted and attempt to use it's dangling raw pointer to a
deleted IndexedDBBackingStore instance.

Also in this change is the elimination of the redundant aborted_
member variable.

BUG= 472614 

Review URL:

Cr-Commit-Position: refs/heads/master@{#326597}


Status: Fixed
The speculative fix in #13 _might_ fix this, and if not will hopefully shed more light on the cause. Being as I cannot reproduce this I am marking as Fixed and will revisit this issue if reopened.
Project Member

Comment 15 by ClusterFuzz, Apr 24 2015

Labels: -Restrict-View-SecurityTeam M-43 Restrict-View-SecurityNotify Merge-Triage
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

- Your friendly ClusterFuzz
Labels: -M-42 -Nag -M-43 -Merge-Triage Merge-NA M-44 Release-0-M44
We can let this roll in with M44 or reopen if the issue isn't fixed. 

(Note: If reopening, please remove the "Release-0-M44" and "Merge-NA" labels.
Labels: CVE-2015-1276
Project Member

Comment 18 by ClusterFuzz, Jul 31 2015

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Labels: -reward-topanel reward-3500 reward-unpaid
Congrats - $3500 for this report ($3000 for the bug + $500 ClusterFuzz bonus).

I'll start payment next week, so you should have the reward ~2 weeks from today.

Thanks again!
Labels: -reward-unpaid reward-inprocess
Labels: -reward-inprocess
Payment is on its way - should arrive in ~7 days. Thanks again for your report!
Project Member

Comment 22 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 23 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment