New issue
Advanced search Search tips

Issue 834947 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 16
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Heap-use-after-free in [thunk]:rtc::VideoSourceInterface<class

Project Member Reported by ClusterFuzz, Apr 19 2018

Issue description

Detailed report: https://clusterfuzz.com/testcase?key=5474710415212544

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_content_shell
Platform Id: windows

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x1285e2d95c30
Crash State:
  [thunk]:rtc::VideoSourceInterface<class
  base::internal::Invoker<struct base::internal::BindState<void
  base::PostTaskAndReplyRelay::RunTaskAndPostReply
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=549043:549044

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5474710415212544

Issue filed automatically.

See https://github.com/google/clusterfuzz-tools for more information.
 
Project Member

Comment 1 by ClusterFuzz, Apr 19 2018

Components: Internals>Core
Labels: Test-Predator-Auto-Components
Automatically applying components based on crash stacktrace and information from OWNERS files.

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

Comment 2 by ClusterFuzz, Apr 19 2018

Labels: Test-Predator-Auto-Owner
Owner: horo@chromium.org
Status: Assigned (was: Untriaged)
Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/8a81ad1578024ba2d76fe820a1666c7f92f76dcf (Introduce Mojo API for SignedHTTPExchange LayoutTests).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.
Project Member

Comment 3 by sheriffbot@chromium.org, Apr 20 2018

Labels: M-67
Project Member

Comment 4 by sheriffbot@chromium.org, Apr 20 2018

Labels: ReleaseBlock-Stable
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
Project Member

Comment 5 by sheriffbot@chromium.org, Apr 20 2018

Labels: Pri-1

Comment 6 by horo@chromium.org, Apr 20 2018

Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
I don't know why but ShellBrowserContext and StoragePartitionImpl are deleted before WebPackageContext::SetSignedExchangeVerificationTimeForTesting() is called.

This code is only in content_shell not in chrome. And it is executed only in LayoutTests.
So setting Pri 2 and removing ReleaseBlock-Stable.

Comment 7 by horo@chromium.org, Apr 20 2018

Cc: kinuko@chromium.org ksakamoto@chromium.org kouhei@chromium.org
Project Member

Comment 8 by sheriffbot@chromium.org, Apr 21 2018

Labels: -Security_Impact-Head Security_Impact-Beta
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 21 2018

Labels: ReleaseBlock-Stable
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

Comment 10 by horo@chromium.org, Apr 21 2018

Labels: -Security_Severity-High -Security_Impact-Beta -ReleaseBlock-Stable Security_Impact-None Security_Severity-Low
Project Member

Comment 11 by ClusterFuzz, May 7 2018

ClusterFuzz has detected this issue as fixed in range 556376:556377.

Detailed report: https://clusterfuzz.com/testcase?key=5474710415212544

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_content_shell
Platform Id: windows

Crash Type: Heap-use-after-free READ 8
Crash Address: 0x1285e2d95c30
Crash State:
  [thunk]:rtc::VideoSourceInterface<class
  base::internal::Invoker<struct base::internal::BindState<void
  base::PostTaskAndReplyRelay::RunTaskAndPostReply
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=549043:549044
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=556376:556377

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5474710415212544

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
Project Member

Comment 12 by ClusterFuzz, May 7 2018

Labels: ClusterFuzz-Verified
Status: Verified (was: Assigned)
ClusterFuzz testcase 5474710415212544 is verified as fixed, so closing issue as verified.

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

Comment 13 by horo@chromium.org, May 7 2018

Status: Assigned (was: Verified)
I don't think this was fixed.

This is a timing issue of the finalization sequence of BlinkTestController.
"main_runner->Run();" (or "run_loop.Run()" for Android) in RunOneTest() of
layout_test_browser_main.cc is executed for one LayoutTest.
This Run() method returns when a QuitClosure is executed.

In normal case, the QuitClosure is PostTasked in the following sequence:
 - BlinkTestRunner::TestFinished() in renderer
  -> LayoutTestHostMsg_InitiateCaptureDump IPC [*1]
 - LayoutTestMessageFilter::OnInitiateCaptureDump() in browser
  -> BlinkTestController::OnInitiateCaptureDump()
   -> LayoutTestControl::CaptureDump() mojo IPC
 - LayoutTestRenderFrameObserver::CaptureDump() in renderer
  -> callback
 - BlinkTestController::OnCaptureDumpCompleted() in browser
  -> BlinkTestController::ReportResults()
   -> BlinkTestController::OnTestFinished() [*2]
     barrier_closure for 3 callbacks
      |-> ClearAllServiceWorkersForTest()
      |-> TerminateAllSharedWorkersForTesting()
      |-> SetSignedExchangeVerificationTimeForTesting() [*3]
     - BlinkTestController::OnCleanupFinished()
      -> ShellViewMsg_Reset IPC
 - BlinkTestRunner::OnReset() in renderer
  -> ShellViewHostMsg_ResetDone IPC
 - BlinkTestController::OnResetDone() in browser
   base::ThreadTaskRunnerHandle::Get()->PostTask(
       FROM_HERE, base::MessageLoop::QuitWhenIdleClosure()); [*]

If window.close() is called in the test, two QuitClosures are PostTasked in the
destructor of a Shell object and in BlinkTestController::DiscardMainWindow().
 - DOMWindow::close() in renderer
  - Page::CloseSoon()
   - FrameLoader::StopAllLoaders()
    - DocumentLoader::StopLoading()
     - ...
      - BlinkTestRunner::TestFinished()
       -> LayoutTestHostMsg_InitiateCaptureDump IPC [==>*1]
   - RenderWidget::CloseWidgetSoon()
    => PostTask(RenderWidget::DoDeferredClose)
 - RenderWidget::DoDeferredClose() in renderer
  => ViewHostMsg_Close IPC
 - RenderViewHostImpl::OnClose() in browser
  - ...
   - Shell::~Shell()
     base::ThreadTaskRunnerHandle::Get()->PostTask(
         FROM_HERE, base::MessageLoop::QuitWhenIdleClosure()); [*]
    - WebContentsImpl::~WebContentsImpl()
     - BlinkTestController::WebContentsDestroyed()
      - BlinkTestController::DiscardMainWindow()
         base::ThreadTaskRunnerHandle::Get()->PostTask(
             FROM_HERE, base::MessageLoop::QuitWhenIdleClosure()); [*]

If a QuitClosure is PostTasked right after BlinkTestController::OnTestFinished()
is called [*2], the StoragePartition could be deleted before the task of
SetSignedExchangeVerificationTimeForTesting [*3] is executed.
Touching the deleted storage partition's WebPackageContext is causing this
use-after-free.

To fix this issue, we should make the WebPackageContext RefCountedThreadSafe and
have WebPackageContextCore which is similar to ServiceWorkerContextCore.
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-None Type-Bug
Removing security labels since this seems to be test only.
Status: Fixed (was: Assigned)
I think this was fixed by 245821d0c52eb90549eff1e4e2ba4a4bfb619a1b which removed WebPackageContext.

Sign in to add a comment