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 reference counting underflow in OffscreenCreateDocumentFunction can lead to a Use-After-Free in the browser process during profile shutdown. This is caused by multiple paths triggering an unconditional Release() of a manually managed reference. If an asynchronous task is pending, the object may be destroyed prematurely, leading to a crash or memory corruption when the task executes.

Affected files:

• extensions/browser/api/offscreen/offscreen_api.cc
• extensions/browser/extension_function.cc

Estimated timestamp from git blame: Unknown (Google3 checkout)

Description

A potential Use-After-Free (UAF) vulnerability exists in the browser process within the OffscreenCreateDocumentFunction class. The class manually manages its lifetime using AddRef() and Release() to handle asynchronous responses. However, during BrowserContext (profile) shutdown, two independent code paths can trigger Release() back-to-back without verifying if the reference has already been consumed. This leads to a reference count underflow, potentially deleting the object while an asynchronous task still holds a reference to it.

Technical Details

In OffscreenCreateDocumentFunction::Run(), a manual reference is added to ensure the object stays alive until it can respond to the extension or the context is shut down:

// extensions/browser/api/offscreen/offscreen_api.cc
host_observer_.Observe(offscreen_document);
AddRef();
return RespondLater();

This reference is intended to be balanced by a single Release() call in either OnBrowserContextShutdown() or SendResponseToExtension(). However, both methods call Release() unconditionally:

void OffscreenCreateDocumentFunction::OnBrowserContextShutdown() {
  host_observer_.Reset();
  Release();  // Balanced in Run().
}

void OffscreenCreateDocumentFunction::SendResponseToExtension(ResponseValue response_value) {
  host_observer_.Reset();
  Respond(std::move(response_value));
  Release();  // Balanced in Run().
}

During profile teardown (e.g., closing an incognito window), OffscreenDocumentManager::Shutdown() is executed, which destroys the OffscreenDocumentHost. This triggers OnExtensionHostDestroyed(), which calls SendResponseToExtension() and performs the first Release(). Subsequently, the ExtensionFunction shutdown notifier triggers OnBrowserContextShutdown(), performing a second Release().

Use-After-Free Mechanism

The vulnerability is potentially reachable if a navigation error occurs in the offscreen document. In OnExtensionHostDidStopFirstLoad, if an error page is detected, a task is posted to the UI thread:

base::SingleThreadTaskRunner::GetCurrentDefault()->PostTask(
    FROM_HERE,
    base::BindOnce(&OffscreenCreateDocumentFunction::NotifyPageFailedToLoad,
                   this));

base::BindOnce stores a scoped_refptr to this in the task state, incrementing the refcount. If profile teardown occurs while this task is pending, the double Release() will decrement the refcount twice, causing the object to be deleted despite the pending task. When the task eventually executes NotifyPageFailedToLoad(), it dereferences the freed this pointer.

Potential Impact

This issue resides in the unsandboxed browser process. A compromised renderer or a malicious extension with the offscreen permission could potentially trigger this UAF to cause a browser crash or achieve memory corruption, which may facilitate a sandbox escape.

Potential Reproduction Steps

1. Install a Manifest V3 extension with the offscreen permission and split incognito mode enabled.
2. From an incognito context, call chrome.offscreen.createDocument() with a URL that results in a navigation error (e.g., a non-existent extension resource).
3. Immediately close the incognito profile (e.g., close the last incognito window).
4. If the profile teardown occurs while the NotifyPageFailedToLoad task is pending in the UI thread queue, the object may be over-released and freed, causing a UAF upon task execution.

Suggested Fix

The OffscreenCreateDocumentFunction should ensure that the manual reference is released exactly once. This can be achieved by checking if the function has already responded or by using a boolean flag to track the manual reference’s state. Ideally, the class should avoid manual reference counting in favor of safer patterns like base::WeakPtr or relying solely on scoped_refptr management through the task runner and dispatcher.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.