Low chrome UAF 🔧 Commit mapped

Overview

Low
Severity
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactUse after free in Installer
DescriptionUse after free in Installer
ComponentInstaller
Bug ClassUAF
Tracker513264273
Fix commitb30f43568509 (chromium/src) +12/-3
CISA KEVNot listed
CreditedGoogle
Disclosed2026-06-30

Changed Functions

FunctionChangeNotes
if
chrome/windows_services/service_program/process_wrl_module.cc
modified

Files Changed

  • chrome/windows_services/service_program/process_wrl_module.cc
From b30f435685098c782553d4b124b1e3e8a2cd46d7 Mon Sep 17 00:00:00 2001
From: S Ganesh <[email protected]>
Date: Thu, 21 May 2026 11:40:19 -0700
Subject: [PATCH] Synchronize ModuleReleaseHelper callback access to prevent races

Access to `ModuleReleaseHelper::callback_` is unsynchronized. In
scenarios where multiple COM RPC threads drive the Microsoft Windows
Runtime Library (WRL) module's object count to zero concurrently (e.g.,
rapid failures in `IClassFactory::CreateInstance`), multiple threads can
execute `ModuleReleaseHelper::OnModuleReleased` simultaneously. Because
`base::OnceCallback::Run()` is not thread-safe, this causes a
Use-After-Free (UAF) or Double-Free of the callback's internal
`BindState`.

This CL adds synchronization using a `base::Lock` in
`ModuleReleaseHelper`. Both `SetModuleReleasedCallback` and
`OnModuleReleased` now access `callback_` under the lock. In
`OnModuleReleased`, the callback is moved to a local variable under the
lock and executed outside of the lock to avoid holding the lock during
callback execution.

Bug: 513264273
Change-Id: I328d87ba6da38ed15eae73e87744c61ca6420e54
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7858344
Reviewed-by: Greg Thompson <[email protected]>
Commit-Queue: S Ganesh <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1634431}
---

diff --git a/chrome/windows_services/service_program/process_wrl_module.cc b/chrome/windows_services/service_program/process_wrl_module.cc
index 207ba58..76e9021 100644
--- a/chrome/windows_services/service_program/process_wrl_module.cc
+++ b/chrome/windows_services/service_program/process_wrl_module.cc
@@ -9,6 +9,8 @@
 #include <utility>
 
 #include "base/no_destructor.h"
+#include "base/synchronization/lock.h"
+#include "base/thread_annotations.h"
 
 namespace {
 
@@ -27,14 +29,20 @@
   // Sets the callback to be run when the last reference to the module is
   // released.
   void SetModuleReleasedCallback(base::OnceClosure callback) {
+    base::AutoLock lock(lock_);
     callback_ = std::move(callback);
   }
 
   // A method invoked by the WRL::Module's release notifier. Runs the held
   // callback, if any.
   void OnModuleReleased() {
-    if (callback_) {
-      std::move(callback_).Run();
+    base::OnceClosure callback;
+    {
+      base::AutoLock lock(lock_);
+      callback = std::move(callback_);
+    }
+    if (callback) {
+      std::move(callback).Run();
     }
   }
 
@@ -43,7 +51,8 @@
 
   ModuleReleaseHelper() = default;
 
-  base::OnceClosure callback_;
+  base::Lock lock_;
+  base::OnceClosure callback_ GUARDED_BY(lock_);
 };
 
 }  // namespace
Loading diff…

Original Bug Report

The reporter's bug is still restricted on the tracker. Chrome de-restricts security bugs ~30–90 days after the fix ships; a later run will backfill it here.