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 Use-After-Free (UAF) vulnerability exists in the Windows-specific Web Share implementation. OutputStreamWriteOperation transitively owns resources that must only be destroyed on the IO thread. When its final reference is released on an arbitrary thread by Windows COM delegates, off-sequence destruction of non-atomic ref-counted blob items can lead to a race condition and subsequent memory corruption in the unsandboxed browser process.

Affected files:

• chrome/browser/webshare/win/share_operation.cc
• storage/browser/blob/blob_data_snapshot.h
• storage/browser/blob/blob_data_item.h

Estimated timestamp from git blame: 2020-10-28

Root Cause Analysis

In chrome/browser/webshare/win/share_operation.cc, ShareOperation::PutShareContentInDataPackage creates an OutputStreamWriteOperation for each shared file and registers an IStreamedFileDataRequestedHandler COM delegate callback:

auto operation = base::MakeRefCounted<OutputStreamWriteOperation>(...);
...
auto raw_data_requested_callback =
    Callback<IStreamedFileDataRequestedHandler>(
        [operation](IOutputStream* stream) -> HRESULT {
          operation->WriteStream(stream,
                                 base::DoNothingWithBoundArgs(operation));
          return S_OK;
        });

The scoped_refptr<OutputStreamWriteOperation> is captured by the Windows Runtime (WRL) Callback object, which is passed to Windows via IStorageFileStatics::CreateStreamedFileAsync. Once the registration loop terminates, Windows retains the sole strong reference to this COM delegate.

When Windows eventually releases the delegate (e.g., when the target application releases the streamed StorageFile), the destruction callback runs on an arbitrary Windows thread-pool or COM thread. As a result, the ~OutputStreamWriteOperation destructor executes off-sequence on a non-IO thread.

Thread-Safety Violation on Blob Resources

During its execution, OutputStreamWriteOperation populates the following members on the IO thread:

writer_delegate_ = std::make_unique<storage::FileWriterDelegate>(
    std::make_unique<DataWriterFileStreamWriter>(...),
    storage::FlushPolicy::FLUSH_ON_COMPLETION);
writer_delegate_->Start(
    blob_handle_->CreateReader(),
    base::BindRepeating(&OutputStreamWriteOperation::OnFileWritten,
                        weak_factory_.GetWeakPtr()));

This sets up a ownership and destruction chain:

1. OutputStreamWriteOperation owns a FileWriterDelegate (storage/browser/file_system/file_writer_delegate.h).
2. FileWriterDelegate owns a BlobReader (storage/browser/blob/blob_reader.h).
3. BlobReader owns a BlobDataSnapshot (storage/browser/blob/blob_reader.h).
4. BlobDataSnapshot holds a list of scoped_refptr<BlobDataItem> objects.

BlobDataSnapshot explicitly documents that it must be deleted on the IO thread. BlobDataItem uses non-atomic (non-thread-safe) reference counting:

class BlobDataItem : public base::RefCounted<BlobDataItem> { ... };

When ~OutputStreamWriteOperation executes on a non-IO thread, it triggers the synchronous destruction of FileWriterDelegate, BlobReader, and BlobDataSnapshot, performing non-atomic Release() decrements on BlobDataItem objects from an arbitrary background thread.

Potential Steps to Trigger

Because this is based on static code analysis, the following are potential steps that an attacker operating from a compromised renderer might use to trigger the race condition:

1. The renderer initiates a Web Share operation containing a file associated with a specific Blob.
2. Once the share target begins streaming the file data, the browser instantiates the IO-thread resources.
3. The renderer concurrently and rapidly drives reference-count mutations on the same underlying Blob (e.g., via rapid URL.createObjectURL / URL.revokeObjectURL calls) to perform AddRef() and Release() operations on the IO thread.
4. When the file transfer finishes or is aborted, Windows releases the COM delegate off-thread, running ~BlobDataSnapshot and decrementing the non-atomic refcount of BlobDataItem concurrently.
5. The non-atomic race causes a lost reference increment/decrement, leading to a premature delete of a BlobDataItem while a reference is still held in the registry.
6. A subsequent access to this item on the IO thread triggers a Use-After-Free (UAF) in the unsandboxed browser process.

Suggested Fix

To resolve this issue, ensure that OutputStreamWriteOperation and its thread-affine members are safely destroyed on the correct sequence. Because OutputStreamWriteOperation inherits from RefCountedThreadSafe, a custom deleter can be specified to force destruction on the IO thread:

class OutputStreamWriteOperation
    : public base::RefCountedThreadSafe<OutputStreamWriteOperation,
                                        content::BrowserThread::DeleteOnIOThread> {
  // ...
};

Alternatively, specify a custom task runner when releasing sequence-affine members (like writer_delegate_ and blob_handle_) or post a task to delete them on the IO thread.

Evaluated with Chrome root at commit: a2bea94528f4bd6cc57739c43fa3bb890b8367d3

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.