ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=6502394742177792.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=6217234012438528.

I'm having a bit of trouble reproducing this one, even using an HTTP server.

rockot: Any chance that this could be related to https://chromium-review.googlesource.com/c/chromium/src/+/1141078? Since I can't repro it's a bit of a shot in the dark, so feel free to pass it back to me for retriage if not.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 868724  has been merged into this issue.

Testcase 6217234012438528 failed to reproduce the crash. Please inspect the program output at https://clusterfuzz.com/testcase?key=6217234012438528.

Testcase 6502394742177792 failed to reproduce the crash. Please inspect the program output at https://clusterfuzz.com/testcase?key=6502394742177792.

It is conceivable that the CL you suggest is at fault, though it would be quite surprising to me. I have also been unable to repro, but I will keep digging.

Can you help me understand the nature of use-after-poison errors? Is this a matter of memory being accessed after it's been deinitialized but not yet freed? i.e. use during partial destruction? If so, any insight onto how asan hooks in and poisons things when appropriate?

rockot@, your understanding of use-after-poison is correct.

Here is some additional information:
- https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm
- https://github.com/google/sanitizers/issues/73

M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.

Still cannot repro. I have no idea.

Oooh. Managed to get a pretty consistent repro by having a tab open the testcase in a new window. Digging more...

OK, so I have narrowed it down specifically to the blink.mojom.ProgressClient interface, and it's always a binding endpoint in a render process that is at fault. This narrows the issue down to exactly one place, blink::ResourceLoader[1].

I haven't done any further analysis yet. My guess would be that it must be possible for a ResourceLoader to be destroyed from a thread other than the main thread, but that's only a guess. This would be able to explain raciness between destruction and OnProgress message dispatch, and I'm really not sure what else could.

[1] https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_loader.h?rcl=eabf9ad0429004d92823c7594d0b141f97cdead8&l=193

Not sure about the threading behavior of ResourceLoader. But maybe there are potential issues because ResourceLoader is garbage collected, and thus can be in a finalized-but-not-yet-destroyed state? In which case perhaps closing the binding in its Dispose method might be enough.

Aha. Yes, that would perfectly explain what's happening here, and closing the binding sounds like the right thing to do. Thanks for the insight, I'll give that a stab.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0cc45e354863b2aa4d676335bd9aab4ecd50fe2c

commit 0cc45e354863b2aa4d676335bd9aab4ecd50fe2c
Author: Ken Rockot <rockot@chromium.org>
Date: Thu Aug 09 04:06:51 2018

Fix blink::ResourceLoader finalization

This causes blink::ResourceLoader::Dispose() to close the object's
blink.mojom.ProgressClient binding, preventing incoming IPCs from
being dispatched to the finalized object in the interim between
finalization and actual destruction.

Bug:  867370 
Change-Id: I9a14c51cb5d75e11b211006d094d73beafab8922
Reviewed-on: https://chromium-review.googlesource.com/1168289
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581779}
[modify] https://crrev.com/0cc45e354863b2aa4d676335bd9aab4ecd50fe2c/third_party/blink/renderer/platform/loader/fetch/resource_loader.cc

This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+awhalley@ (Security TPM) for M69 merge review.

govind@ - good for 69

Approving merge to M69 branch 3497 based on comment #29. Please merge.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e030fadca784f022be51ca276b4f8e3256bcc3da

commit e030fadca784f022be51ca276b4f8e3256bcc3da
Author: Ken Rockot <rockot@chromium.org>
Date: Tue Aug 14 20:36:57 2018

Fix blink::ResourceLoader finalization

This causes blink::ResourceLoader::Dispose() to close the object's
blink.mojom.ProgressClient binding, preventing incoming IPCs from
being dispatched to the finalized object in the interim between
finalization and actual destruction.

TBR=rockot@chromium.org

(cherry picked from commit 0cc45e354863b2aa4d676335bd9aab4ecd50fe2c)

Bug:  867370 
Change-Id: I9a14c51cb5d75e11b211006d094d73beafab8922
Reviewed-on: https://chromium-review.googlesource.com/1168289
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#581779}
Reviewed-on: https://chromium-review.googlesource.com/1175083
Reviewed-by: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#629}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/e030fadca784f022be51ca276b4f8e3256bcc3da/third_party/blink/renderer/platform/loader/fetch/resource_loader.cc

*** 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.
*********************************

$3,000 for this report, many thanks!

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot