latest chrome asan build stacktrace:

==1==ERROR: AddressSanitizer: use-after-poison on address 0x7ed26f3a7c10 at pc 0x55ab38a4a65c bp 0x7ffdb162b710 sp 0x7ffdb162b708
READ of size 8 at 0x7ed26f3a7c10 thread T0 (chrome)
    #0 0x55ab38a4a65b in content::WebURLLoaderImpl::Context::OnReceivedResponse(content::ResourceResponseInfo const&) ./out/Release/../../content/child/web_url_loader_impl.cc:770:14
    #1 0x55ab2fc070e4 in content::ResourceDispatcher::OnReceivedResponse(int, content::ResourceResponseHead const&) ./out/Release/../../content/child/resource_dispatcher.cc:240:23
    #2 0x55ab2fc1170a in DispatchToMethodImpl<content::ResourceDispatcher *, void (content::ResourceDispatcher::*)(int, const content::ResourceResponseHead &), const std::__1::tuple<int, content::ResourceResponseHead> &, 0, 1> ./out/Release/../../base/tuple.h:144:3
    #3 0x55ab2fc1170a in DispatchToMethod<content::ResourceDispatcher *, void (content::ResourceDispatcher::*)(int, const content::ResourceResponseHead &), const std::__1::tuple<int, content::ResourceResponseHead> &> ./out/Release/../../base/tuple.h:151:0
    #4 0x55ab2fc1170a in DispatchToMethod<content::ResourceDispatcher, void (content::ResourceDispatcher::*)(int, const content::ResourceResponseHead &), void, std::__1::tuple<int, content::ResourceResponseHead> > ./out/Release/../../ipc/ipc_message_templates.h:26:0
    #5 0x55ab2fc1170a in bool IPC::MessageT<ResourceMsg_ReceivedResponse_Meta, std::__1::tuple<int, content::ResourceResponseHead>, void>::Dispatch<content::ResourceDispatcher, content::ResourceDispatcher, void, void (content::ResourceDispatcher::*)(int, content::ResourceResponseHead const&)>(IPC::Message const*, content::ResourceDispatcher*, content::ResourceDispatcher*, void*, void (content::ResourceDispatcher::*)(int, content::ResourceResponseHead const&)) ./out/Release/../../ipc/ipc_message_templates.h:121:0
    #6 0x55ab2fc056a5 in content::ResourceDispatcher::DispatchMessage(IPC::Message const&) ./out/Release/../../content/child/resource_dispatcher.cc:569:5
    #7 0x55ab2fc03d2b in content::ResourceDispatcher::OnMessageReceived(IPC::Message const&) ./out/Release/../../content/child/resource_dispatcher.cc:190:3
    #8 0x55ab27df10fd in Run ./out/Release/../../base/callback.h:47:12
    #9 0x55ab27df10fd in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./out/Release/../../base/debug/task_annotator.cc:52:0
    #10 0x55ab300b0a0d in blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*) ./out/Release/../../third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:378:19
    #11 0x55ab300ab319 in blink::scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool) ./out/Release/../../third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:253:13
    #12 0x55ab27df10fd in Run ./out/Release/../../base/callback.h:47:12
    #13 0x55ab27df10fd in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) ./out/Release/../../base/debug/task_annotator.cc:52:0
    #14 0x55ab27bfedc7 in base::MessageLoop::RunTask(base::PendingTask*) ./out/Release/../../base/message_loop/message_loop.cc:413:19
    #15 0x55ab27bff7df in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) ./out/Release/../../base/message_loop/message_loop.cc:422:5
    #16 0x55ab27c00a9a in base::MessageLoop::DoWork() ./out/Release/../../base/message_loop/message_loop.cc:515:13
    #17 0x55ab27c0d3dd in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) ./out/Release/../../base/message_loop/message_pump_default.cc:35:31
    #18 0x55ab27bfe103 in base::MessageLoop::RunHandler() ./out/Release/../../base/message_loop/message_loop.cc:378:10
    #19 0x55ab27c8f134 in base::RunLoop::Run() ./out/Release/../../base/run_loop.cc:35:10
    #20 0x55ab350d47ab in content::RendererMain(content::MainFunctionParams const&) ./out/Release/../../content/renderer/renderer_main.cc:198:23
    #21 0x55ab26ce08e4 in content::RunZygote(content::MainFunctionParams const&, content::ContentMainDelegate*) ./out/Release/../../content/app/content_main_runner.cc:336:14
    #22 0x55ab26ce5133 in content::ContentMainRunnerImpl::Run() ./out/Release/../../content/app/content_main_runner.cc:776:12
    #23 0x55ab26cdf66d in content::ContentMain(content::ContentMainParams const&) ./out/Release/../../content/app/content_main.cc:20:28
    #24 0x55ab21130552 in ChromeMain ./out/Release/../../chrome/app/chrome_main.cc:97:12
    #25 0x7f1f3325582f in __libc_start_main ??:0:0

Address 0x7ed26f3a7c10 is a wild pointer.
SUMMARY: AddressSanitizer: use-after-poison (/home/fuzzer/browsers/chrome/chrome+0x1a94465b)
Shadow bytes around the buggy address:
  0x0fdacde6cf30: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 00 00
  0x0fdacde6cf40: 00 00 f7 00 00 00 00 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cf50: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cf60: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cf70: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
=>0x0fdacde6cf80: f7 f7[f7]f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cf90: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cfa0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cfb0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cfc0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
  0x0fdacde6cfd0: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1==ABORTING

Hi, thanks for the report. Do you have a repro? I don't think this is a duplicate.

Not so far, however this occasionally appear in one of my fuzzers with both builds mentioned above. I've been browsing old bugs like #163218 but this seems related to Glue. I'm going to browse to see if I can play it by hand. Any help is welcome, thank you.

WebURLLoaderImpl::Context holds a pointer to a ResourceLoader (or perhaps a PingLoaderImpl) in the client_ field. It appears that client_ is being destroyed before WebURLLoaderImpl::Context::OnReceivedResponse runs.

I am not familiar with how this pointer interacts with oilpan scanning. Mind taking a look, kinuko@?

Any update?

kinuko: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Would you mind uploading a testcase to reproduce the issue?

I do not have repro for this issue

kinuko: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

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

kinuko/yhirano: ping on this one. It looks like a lifetime issue on WebURLLoaderImpl::Context. Can you urgently have a look?

https://chromium.googlesource.com/chromium/src/+/6e6d7a20f7cb4b23ff305b16579faf94f7ddf992 could fix the issue, but I cannot prove that.

Sorry this has slipped under my radar.  My hope was also that yhirano's change would have fixed it, but will look if this is still happening.

So fixed without acknowledgement, great!

Hmm, it looks this is still happening after the change. I'll try to make some speculative fix or add some checks.

kinuko@, do you have any crash links?

Like this one?

crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27content%3A%3AWebURLLoaderImpl%3A%3AContext%3A%3AOnReceivedResponse%27%20AND%20product.Version%3D%2757.0.2987.133%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=4aae958a10000000&index=0

(Fyi, 57.0.2980.0 is the release the fix landed)

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

commit a0b150ffc2dcafc7b302da312523e6c7ff80e8d6
Author: kinuko <kinuko@chromium.org>
Date: Fri Apr 07 09:40:24 2017

Add CHECK in PingLoaderImpl's destructor

BUG= 662769 
R=yhirano@chromium.org

Review-Url: https://codereview.chromium.org/2798393006
Cr-Commit-Position: refs/heads/master@{#462821}

[modify] https://crrev.com/a0b150ffc2dcafc7b302da312523e6c7ff80e8d6/third_party/WebKit/Source/core/loader/PingLoader.cpp

ping @kinuko 

Is this planned to be fixed on release 58 this month?

Release 58 is already cut and it won't have a fix for this one, sorry for that.  I'm having trouble narrowing down the cause of how this is happening.

this bug is from 7th November, remove security labels to be disclosed. 

We automatically open up bugs ~14 weeks after they are fixed (https://www.chromium.org/Home/chromium-security/security-faq#TOC-Can-you-please-un-hide-old-security-bugs-).

Unfortunately, this issue was assigned to someone who was OOO in November, so it's slipped our usual deadlines. Our reward guidelines mean that to be eligible for an award, bugs can't be disclosed until a fix is landed.

kinuko, yhirano, can we try and urgently move this one along? We've really dropped the ball here sadly.

Note that it was not kinuko who dropped the ball! This mistake is on us, Chrome Security.

rs, we apologize for that. You should have been able to take this bug public and have the bug be considered for the VRP by now. But if you can bear with us for just a bit longer, we'll make things right and make sure this doesn't happen again.

Thanks to everyone for your patience and hard work. :)

[reposted to fix a typo]

This bug wouldn't seem to be Linux- or x64-specific; tweaking the labels to suit.

Sorry for all the delay again. We'll try not to make this happen again in our side too.

Will try moving this along asap.

Yes, when I said "we've really dropped the ball" earlier I meant the Security team, not the assignees. Thanks for the work here and to the bug reporter for prodding us on this. :)

Please remove the restrictions of this bug now if will not be fixed on 58 release this month.

#33: It's not a great idea to make a Security_Severity-High bug public without a fix, so we're going to keep it private until it's fixed.

#34 Google missed > 90days disclosure deadline. 

Keep in mind that the lack of a repro case makes bug-hunting significantly more difficult. For example, when Project Zero files a bug with a 90-day disclosure limit, it's with a reliable repro case.

And, you're free to make the bug public if you like, at any time. It's just that doing so disqualifies you for a VRP reward for this bug.

I fully understand that, what I have requested is a deadline of the next release (58) that I consider fair. I believe 90 days is more than enough to understand the two stacktrace by a team of maintainers and Security. So far the VRP program will only tell me the amount once it has been patched and can be in 3 more months? Who knows, I will not wait 3 months for a sum of money that I do not even know.

Let me add a bit more context: basically we think that the patch mentioned earlier in this bug must have fixed the cause of the use-after-poison crash that was raised in the original post, and # of crashes that has the same method name in the stack signature has actually dropped like 1/20 after the patch.  However as I wrote in #20 we still have small # of crashes around the method.  We think it's likely due to different crashes but we can't prove it without a reliable repro.  Sorry for the disambiguity, but this is all I can tell right now.

That patch landed 3 months ago, it might be reasonable to close this bug as fixed.

Recent crashes in that method are very rare and don't look exploitable -- dereferencing small offsets of null pointers.

#38: Have you managed to reproduce the use-after-poison in recent builds? Without evidence that the bug still repros, or any insight into potential causes, it isn't possible to do any more on this.

#40 Close the bug as fixed.

Ok, let me close this bug now. Thanks to everyone for your patience and help.

Sending this to the VRP panel for consideration.

OK to open this up now, per awhalley.

Hi rs@ - just wanted to update you on the results of the VRP panel.  They decided not to award for this bug, I'm afraid.  The report was low quality, only including a crash dump and no additional analysis or, proof of concept, or reproduction case. And the fix that was made in #23 was only to catch the symptom, not to address the root cause (see https://chromium.googlesource.com/chromium/src.git/+/a0b150ffc2dcafc7b302da312523e6c7ff80e8d6%5E%21/#F0)
We'd be willing to reconsider if you could provide reproduction steps or other information that could help us find and fix the root cause.  Thanks!

Double checked before removing the CHECK (https://chromium-review.googlesource.com/c/517549/)

No crashes found for 59 and later.

REGEXP(product.name, '^Chrome')
  AND REGEXP(product.version, '^(58|59|60|61)\\.')
  AND crash.reason != 'EXCEPTION_BREAKPOINT'
  AND crash.reason != 'Out of Memory'
  AND custom_data.ChromeCrashProto.malware_verdict = false
  OMIT RECORD IF
    SUM(REGEXP(CrashedStackTrace.StackFrame.FunctionName,
               'PingLoaderImpl::~PingLoaderImpl')) = 0

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

commit c2242c72c6c1ffa78f656f8cddf137bafa66ed6b
Author: Takeshi Yoshino <tyoshino@chromium.org>
Date: Fri Jun 02 09:07:29 2017

Change the CHECK in PingLoaderImpl destructor to DCHECK

Bug:  662769 
Change-Id: I273e82bc46447a407f5129b759b1ed5936a2cab5
Reviewed-on: https://chromium-review.googlesource.com/517549
Commit-Queue: Takeshi Yoshino <tyoshino@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#476606}
[modify] https://crrev.com/c2242c72c6c1ffa78f656f8cddf137bafa66ed6b/third_party/WebKit/Source/core/loader/PingLoader.cpp