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 without the Chrome Security team. Please see go/chrome-ai-generated-security-bugs-faq for more information.

Overview: During payment app deduplication, Java JniPaymentApp references are dropped without explicitly cleaning up their native C++ counterparts. When Android’s Garbage Collector later finalizes these objects on a background thread, it synchronously destroys UI-thread-affine C++ objects like SecurePaymentConfirmationApp. This triggers off-thread modification of the WebContents observer list, causing concurrent memory mutation and potential heap corruption in the privileged Browser process.

Affected files:

• components/payments/content/android/java/src/org/chromium/components/payments/PaymentAppService.java
• components/payments/content/android/java/src/org/chromium/components/payments/JniPaymentApp.java
• components/payments/content/secure_payment_confirmation_app.h
• components/payments/content/service_worker_payment_app.h
• components/webauthn/content/browser/internal_authenticator_impl.h

Estimated timestamp from git blame: 2024-10-01

Summary

There is a potential thread-safety vulnerability in the Android PaymentApp implementation. The Java-side PaymentAppService drops references to native-backed JniPaymentApp objects without calling their explicit cleanup method (dismissInstrument()). Relying on the Java Garbage Collector to finalize these objects results in C++ destructors executing on the Android FinalizerDaemon thread instead of the Browser UI thread. Because these C++ objects observe WebContents, destroying them off-thread leads to a data race in base::ObserverList, allowing an attacker to corrupt the heap in the Browser process.

Vulnerability Details

1. In PaymentAppService.java, the deduplicatePaymentApps method filters out redundant payment apps (for example, hiding a Service Worker payment app if a preferred native Android app is present).
2. When an app is filtered out, it is removed from the local collections (e.g., uniquePaymentApps) and the temporary mPossiblyDuplicatePaymentApps list is cleared. The references are dropped without invoking dismissInstrument().
3. The unreferenced JniPaymentApp instances become eligible for Java Garbage Collection.
4. When the GC runs, the Android FinalizerDaemon thread executes JniPaymentApp.finalize(), which calls dismissInstrument() and crosses the JNI boundary to invoke JniPaymentApp::FreeNativeObject(env).
5. FreeNativeObject executes delete this;, which destroys the underlying C++ PaymentApp object (such as SecurePaymentConfirmationApp or ServiceWorkerPaymentApp) entirely on the background FinalizerDaemon thread.
6. SecurePaymentConfirmationApp inherits from content::WebContentsObserver. Its destructor implicitly calls ~WebContentsObserver(), which invokes WebContentsImpl::RemoveObserver(this).
7. WebContentsImpl::RemoveObserver calls RemoveObserver on its base::ObserverList.
8. If base::ObserverList currently has no active iterators (live_iterators_.empty()), it bypasses its internal sequence checker and directly calls observers_.erase(it) on its underlying std::vector.
9. This concurrent std::vector::erase() execution from a background thread races against the Browser UI thread, which frequently reads, iterates, and mutates the same WebContents observer list.

Because std::vector is not thread-safe, this data race causes use-after-free or memory corruption inside the highly-privileged Browser process, potentially leading to a Sandbox Escape and Remote Code Execution (RCE).

Potential Reproduction Steps

Note: Our tooling agent cannot run code yet, so these steps are theoretical based on code analysis.

1. An attacker hosts a malicious website that registers a Service Worker payment handler.
2. The Service Worker’s web-app manifest includes "prefer_related_applications": true and specifies a widely installed Android native payment app as a related application.
3. The attacker’s site invokes a PaymentRequest with methods that match both the Service Worker and the Android native app.
4. During the payment app discovery phase, both apps are instantiated in C++ and Java.
5. PaymentAppService.deduplicatePaymentApps drops the Java reference to the Service Worker app in favor of the native app.
6. The attacker uses memory-intensive JavaScript to apply memory pressure, forcing an Android Garbage Collection.
7. The FinalizerDaemon triggers the C++ destructor off-thread. Concurrent UI actions (like navigating the WebContents or registering a new observer) cause a data race in the ObserverList, crashing or corrupting the Browser process.

Suggested Fix

1. Explicit Cleanup: Update PaymentAppService.java to explicitly call dismissInstrument() on any PaymentApp instances that are discarded during deduplication or when a PaymentRequest is aborted/closed, ensuring resources are freed deterministically on the UI thread.
2. Thread Enforcement: Update JniPaymentApp::FreeNativeObject to ensure the C++ object is always deleted on the UI thread, regardless of which thread initiates it. For example, use content::GetUIThreadTaskRunner({})->DeleteSoon(...) instead of a direct delete this;.

Evaluated with Chrome root at commit: 661452647ddb2827305122ff3273bd5dea403f09

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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.