Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Stack implicates a base::LazyInstance<class ChromeContentGpuClient...>, setting component to GPU.

sadrul@ - looks like you were poking around with GPU threads a few weeks ago, could you take a look or re-assign as appropriate? Thanks.

+wittman@

That's interesting. wittman@ Do you have ideas on what could be going on here?

Hm. This is happening before we even attempt to start the sandbox in the gpu process.

This is crashing trying to execute at address 0x0 within __asan_wrap_CreateThread, presumably because ASAN's CreateThread hook is calling into a null function pointer. This seems like either a problem with ASAN's hooking of CreateThread or a really unlucky memory corruption.

It seems very unlikely that this could be caused by code on the crash stack, which is getting here via the same PlatformThread::Start() invocation that is used by pretty much every other thread within Chrome.

sadrul: 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

Agree with comment#7. Someone more familiar with asan-on-windows should take a look and confirm. +siggi@

Security sheriff ping: siggi@, can you confirm this is some ASAN issue / unlucky memory corruption so I can close this out?

Sorry, I'm not that familiar with ASAN, and I don't have time to tend this.

I think this is all win64-asan instability, needs some help to get it in shape.

I built chrome locally with asan, and I was not able to reproduce this locally. The GPU process seems to start up just fine. wittman@, were you able to reproduce this? Did you use the CF builds or your own local build?

This is the code in ASan's CreateThread interceptor:

INTERCEPTOR_WINAPI(DWORD, CreateThread,
                   void* security, uptr stack_size,
                   DWORD (__stdcall *start_routine)(void*), void* arg,
                   DWORD thr_flags, void* tid) {
  // Strict init-order checking is thread-hostile.
  if (flags()->strict_init_order)
    StopInitOrderChecking();
  GET_STACK_TRACE_THREAD;
  // FIXME: The CreateThread interceptor is not the same as a pthread_create
  // one.  This is a bandaid fix for PR22025.
  bool detached = false;  // FIXME: how can we determine it on Windows?
  u32 current_tid = GetCurrentTidOrInvalid();
  AsanThread *t =
        AsanThread::Create(start_routine, arg, current_tid, &stack, detached);
  return REAL(CreateThread)(security, stack_size,
                            asan_thread_start, t, thr_flags, tid);
}

My best guess for what's happening based on c#7 is that `REAL(CreateThread)` is null. That can happen if code runs before __asan_init runs.

I did not try to reproduce this. This code runs on every GPU process startup under 64-bit Windows and Mac, so if it did reproduce I would expect to see it crashing the GPU process consistently under ASAN.

 Issue 837093  has been merged into this issue.

ClusterFuzz testcase 5142947511926784 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.