Summary: | REGRESSION(r195770): Use-after-free in ResourceLoaderOptions::cachingPolicy | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||
Component: | Page Loading | Assignee: | Jer Noble <jer.noble> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | beidson, cdumez, commit-queue, darin, japhet, jer.noble, webkit-bug-importer | ||||||
Priority: | P2 | Keywords: | EasyFix, InRadar | ||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2016-01-31 11:16:10 PST
Simplest fix is to move the !deleted check before the allowsCaching() check inside the if statement. It’s just an && and we need to short circuit before calling allowsCaching() if deleted is true. Looking into this now. (In reply to comment #3) > It’s just an && and we need to short circuit before calling allowsCaching() > if deleted is true. Yep. It also looks like this is the only place where we call allowsCaching() after deleteIfPossible(). Created attachment 270388 [details]
Patch
Comment on attachment 270388 [details]
Patch
r=me
Comment on attachment 270388 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270388&action=review I like the patch. I would have suggested the smaller one that just reorders the delete check, but it’s good to look over all the logic carefully. Generally I am ever so slightly worried that we have too many allowsCaching() checks. > Source/WebCore/loader/cache/CachedResource.cpp:486 > + // `this` object is dead here. What’s with the peculiar quoting here? I’ve never seen someone use backquotes like this. > Source/WebCore/loader/cache/CachedResource.cpp:499 > + if (!m_switchingClientsToRevalidatedResource) > + allClientsRemoved(); I don’t understand why it’s OK to skip this step when allowsCaching is false. Nothing in the function name "allClientsRemoved" makes that clear, even if in practice the code isn’t needed. > Source/WebCore/loader/cache/CachedResource.cpp:500 > + destroyDecodedDataIfNeeded(); Unclear on the sequence of the code, why it’s best to do this in this order. Also unclear why we want to skip this step when allowsCaching is false. Comment on attachment 270388 [details] Patch Clearing flags on attachment: 270388 Committed r195965: <http://trac.webkit.org/changeset/195965> All reviewed patches have been landed. Closing bug. Comment on attachment 270388 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=270388&action=review I'll address these comments in a follow up patch. >> Source/WebCore/loader/cache/CachedResource.cpp:486 >> + // `this` object is dead here. > > What’s with the peculiar quoting here? I’ve never seen someone use backquotes like this. It's a GitHub / Markdown ism. It translates as "[code]this[/code]". "this" is a ambiguous word, so I just wanted to emphasize that I was talking about the "this" pointer, not some other English-language "this". >> Source/WebCore/loader/cache/CachedResource.cpp:499 >> + allClientsRemoved(); > > I don’t understand why it’s OK to skip this step when allowsCaching is false. Nothing in the function name "allClientsRemoved" makes that clear, even if in practice the code isn’t needed. You're right; we should just be protecting access to the memory cache. >> Source/WebCore/loader/cache/CachedResource.cpp:500 >> + destroyDecodedDataIfNeeded(); > > Unclear on the sequence of the code, why it’s best to do this in this order. Also unclear why we want to skip this step when allowsCaching is false. Since destroyDecodedDataIfNeeded() just starts a timer, I don't think the order matters here. Reopening to attach new patch. Created attachment 270491 [details]
Follow up patch
(iOS build error appears unrelated: "Code Sign error: The file “WebContent-iOS-no-sandbox.entitlements” couldn’t be opened because there is no such file.: (null)") Comment on attachment 270491 [details] Follow up patch Clearing flags on attachment: 270491 Committed r196367: <http://trac.webkit.org/changeset/196367> All reviewed patches have been landed. Closing bug. |