Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential race condition in GoogleUpdater’s AppServerWin::Stop() method on Windows allows unsynchronized concurrent execution of the on_service_stopping_ callback. This can lead to a double-release of the underlying BindState, causing a potential Use-After-Free (UAF) vulnerability. If successfully exploited, a local non-admin user could potentially achieve local privilege escalation to SYSTEM.

Affected files:

• chrome/updater/app/app_server_win.cc
• chrome/updater/app/app_server_win.h

Estimated timestamp from git blame: 2025-12-11

Summary

A potential race condition exists in the Chromium updater’s AppServerWin::Stop() implementation due to unsynchronized access to the on_service_stopping_ callback. This callback is executed when the system-level COM server is shutting down. Because the callback is invoked and moved without thread synchronization, concurrent execution across multiple threads (such as COM RPC threads and the Service Control Manager thread) can cause a double-release of the underlying BindStateBase, potentially leading to a Use-After-Free (UAF) vulnerability.

Root Cause Analysis

In chrome/updater/app/app_server_win.cc, AppServerWin::CreateWRLModule() registers AppServerWin::Stop as the WRL Module release notifier:

void AppServerWin::CreateWRLModule() {
  Microsoft::WRL::Module<Microsoft::WRL::OutOfProc>::Create(
      this, &AppServerWin::Stop);
}

AppServerWin::Stop() can also be called via the SCM (Service Control Manager) dispatcher thread when the service is stopped by the OS.

The Stop() method is implemented as follows:

void AppServerWin::Stop() {
  VLOG(2) << __func__ << ": COM server is shutting down.";
  if (IsSystemInstall(updater_scope())) {
    if (on_service_stopping_) {
      std::move(on_service_stopping_).Run();
    }
  }
  UnregisterClassObjects();
  ...
}

If Thread A (e.g., an SCM stop thread) and Thread B (e.g., a COM RPC thread executing due to a transition to zero objects) call Stop() concurrently, the following sequence of events can occur:

1. Both threads evaluate the if (on_service_stopping_) check as true concurrently before either can clear or move the member variable.
2. Both threads proceed to execute std::move(on_service_stopping_).Run().
3. In base/functional/callback.h, OnceCallback::Run() && moves the internal state holder:

   internal::BindStateHolder holder = std::move(holder_);
   

4. This invokes the move constructor of scoped_refptr<BindStateBase> in base/memory/scoped_refptr.h:

   scoped_refptr(scoped_refptr&& r) noexcept : ptr_(r.ptr_) { r.ptr_ = nullptr; }
   

5. Because this move operation is non-atomic, both threads can copy the same raw pointer address r.ptr_ into their respective local holder variables before either thread assigns nullptr to the source pointer.
6. Both threads successfully execute the check CHECK(!is_null()) and invoke the callback.
7. When the local holder variables on both threads go out of scope, their destructors invoke Release(ptr_) on the same BindStateBase pointer.
8. The first destructor decrements the reference count to 0, deleting the BindState object. The second destructor attempts to release the already-deleted pointer, causing a Use-After-Free.

Because scoped_refptr::ptr_ is annotated with the RAW_PTR_EXCLUSION macro, this smart pointer is not protected by MiraclePtr/BackupRefPtr.

Potential Exploitation Path

Note: These are suggested and potential steps, as our analysis is static and we have not executed a live proof-of-concept.

1. An unprivileged local user logged into an interactive session (who is explicitly granted COM execute permissions via the Interactive SID) activates the updater’s COM classes.
2. The attacker triggers rapid reference additions and releases (or coordinates a COM release with an SCM service stop request) to trigger concurrent invocations of AppServerWin::Stop() on separate threads.
3. If the race condition is successfully triggered, the underlying BindState is double-released.
4. By reclaiming the freed heap memory of the BindState before the second thread’s destructor runs, the attacker could overwrite the destructor_ function pointer.
5. When the second thread executes destructor_(this), control flow is redirected, potentially allowing arbitrary code execution in the context of the service (NT AUTHORITY\SYSTEM). This would result in Local Privilege Escalation (LPE).

Suggested Fix

Protect the access to on_service_stopping_ with a mutex or base::Lock to perform a synchronized move-and-invoke, similar to the pattern utilized in ModuleReleaseHelper within chrome/windows_services/service_program/process_wrl_module.cc:

void AppServerWin::Stop() {
  VLOG(2) << __func__ << ": COM server is shutting down.";
  base::OnceClosure on_stopping;
  {
    base::AutoLock lock(lock_);
    on_stopping = std::move(on_service_stopping_);
  }
  if (on_stopping) {
    std::move(on_stopping).Run();
  }
  UnregisterClassObjects();
  ...
}

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.