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

Issue metadata

Status: Fixed
Closed: Apr 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 0
Type: Bug-Security

Sign in to add a comment

Issue 827492: Security: In-memory Cache UaF

Reported by, Mar 30 2018

Issue description

Incognito mode uses an in-memory cache to avoid writing to disk like the blockfile and simple caches. This mode suffers from an issue with sparse writes similar to the bug reported in , but the issue is limited to a single function.

See the following snippet:

void MemBackendImpl::EvictIfNeeded() {
  if (current_size_ <= max_size_)

  int target_size = std::max(0, max_size_ - kDefaultEvictionSize);

  base::LinkNode<MemEntryImpl>* entry = lru_list_.head();
  while (current_size_ > target_size && entry != lru_list_.end()) {
    MemEntryImpl* to_doom = entry->value();
    entry = entry->next();
    if (!to_doom->InUse())

Eviction traverses the list of entries in the lru_list_. The line `entry = entry->next()` keeps a pointer to the next entry to process while we potentially doom the current entry. There's a problem here: if the next entry is a child of the current entry and neither is in use, the entry pointer on the next iteration will be stale, and dooming it again will lead to a double-doom which manifests as use-after-free.

My attached patch supplies a sample fix for the issue and a unit test to demonstrate it. I resolve the issue by resetting the entry to the lru_list_ head when we encounter a doomable parent. It might be improved by also checking if children are present.

Chrome Version: 65 Stable
Operating System: All (? wherever in-memory cache is deployed)

See attachments

Type of crash: Browser
Crash State: See asan.log
2.5 KB Download
10.3 KB View Download

Comment 1 by, Mar 30 2018

Components: Internals>Network>Cache
Thanks, again!

Comment 2 by, Mar 30 2018

Labels: Security_Severity-Critical M-66 Security_Impact-Stable OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac OS-Windows Pri-0
Status: Assigned (was: Unconfirmed)
jkarlin@, could you please take a look? I can't see a better owner using git blame.

morlovich@, might be helpful, as he's been recently fixing a similar bug in a blockfile cache.


Hey Ned, how many of those you else have? :)

Comment 3 by, Mar 30 2018

Labels: reward-topanel ReleaseBlock-Beta

Comment 4 by, Mar 30 2018

Josh, feel free to dump it on me if you're too busy (though it's all that similar --- if you want similar, see

Comment 5 by, Mar 30 2018

Status: Started (was: Assigned)
I can take this one. Thanks for the report Ned!

Comment 6 by, Mar 30 2018

Sure thing guys! Don't forget to add CacheTestFillBuffer in the unittest to avoid an uninitialized read.. security is hard :p


@mmoroz: maybe one more, but I think these two were the worst. I have one with DoomAllEntries as well but I'm trying to figure out if there's a variant without user interaction. I'm not blocking on it though; I'll figure it out as I'm writing the next report.

Comment 7 by, Mar 30 2018

BTW, I thought about a better patch this morning: if the current entry is a parent and next is one of the children, either reset the next head or just move it forward to a non-child. This prevents needlessly rescanning the list and only does extra work in the exact buggy case.

Comment 8 by, Mar 30 2018

"reset the next head" should read "reset the current entry to head" like in the original patch. Moving next forward until it finds a non-child should be better anyways since we always close the children if the parent is to be closed, so skipping those entries shouldn't miss any doomable entries.

Comment 10 by, Mar 30 2018

Ha, great minds... ;)

Thanks for the quick fixes on these! I know you guys have a lot of responsibility and these types of bugs can interfere with daily development.

Comment 11 by, Mar 30 2018

Project Member
The following revision refers to this bug:

commit c9d673b54832afde658f214d7da7d0453fa89774
Author: Josh Karlin <>
Date: Fri Mar 30 19:24:28 2018

[MemCache] Fix bug while iterating LRU list in eviction

It was possible to reanalyze a previously doomed entry.

Bug:  827492 
Change-Id: I5d34d2ae87c96e0d2099e926e6eb2c1b30b01d63
Commit-Queue: Josh Karlin <>
Reviewed-by: Maks Orlovich <>
Cr-Commit-Position: refs/heads/master@{#547236}

Comment 12 by, Apr 2 2018

Labels: Merge-Request-66
Looks good over the weekend. Requesting beta merge.

Comment 13 by, Apr 2 2018

Project Member
Labels: -Merge-Request-66 Merge-Review-66 Hotlist-Merge-Review
This bug requires manual review: Less than 11 days to go before AppStore submit on M66
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit - Your friendly Sheriffbot

Comment 14 by, Apr 2 2018

Project Member
Status: Fixed (was: Started)
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit - Your friendly Sheriffbot

Comment 15 by, Apr 2 2018

Labels: -Merge-Review-66 Merge-Approved-66

Comment 16 by, Apr 2 2018

Project Member
Labels: -merge-approved-66 merge-merged-3359
The following revision refers to this bug:

commit c1c8fd65cc3100148f6a4b2f203312a741d09b9e
Author: Josh Karlin <>
Date: Mon Apr 02 18:06:43 2018

[MemCache] Fix bug while iterating LRU list in eviction

It was possible to reanalyze a previously doomed entry.

Bug:  827492 
Change-Id: I5d34d2ae87c96e0d2099e926e6eb2c1b30b01d63
Commit-Queue: Josh Karlin <>
Reviewed-by: Maks Orlovich <>
Cr-Original-Commit-Position: refs/heads/master@{#547236}(cherry picked from commit c9d673b54832afde658f214d7da7d0453fa89774)
Reviewed-by: Josh Karlin <>
Cr-Commit-Position: refs/branch-heads/3359@{#531}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}

Comment 17 by, Apr 3 2018

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 18 by, Apr 11 2018

Labels: -ReleaseBlock-Beta

Comment 19 by, Apr 11 2018


Comment 20 by, Apr 17 2018

Labels: Release-0-M66

Comment 21 by, Apr 20 2018

Labels: -reward-topanel reward-unpaid reward-10500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Comment 22 by, Apr 20 2018

Thanks Ned, $10,500 for the report :-)

Comment 23 by, Apr 20 2018

Labels: -reward-unpaid reward-inprocess

Comment 24 by, Apr 20 2018

Thank you!

Comment 25 by, Apr 25 2018

Labels: CVE-2018-6086

Comment 26 by, Apr 25 2018

Labels: CVE_description-missing

Comment 27 by, Jul 10 2018

Project Member
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 28 by, Dec 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment