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 Use-After-Free vulnerability exists in PrintViewManager when initiating a print preview. Showing the preview dialog forces the tab out of HTML fullscreen, which on Windows and macOS spins a nested message loop; closing the tab during this loop destroys the PrintViewManager, leading to a virtual function call on the freed object upon return.

Affected files:

• chrome/browser/printing/print_view_manager.cc

Estimated timestamp from git blame: 2021-09-27

Description

A potential Use-After-Free (UAF) vulnerability has been identified in PrintViewManager::OnRequestPrintPreviewCallback (chrome/browser/printing/print_view_manager.cc).

When a renderer requests a print preview, PrintViewManager calls PrintPreviewDialogController::PrintPreview to display the modal preview dialog. Showing a modal dialog requires dropping HTML Fullscreen mode to ensure the user has context. To do this, BrowserWindowModalDialogDelegate::SetWebContentsBlocked calls web_contents->ExitFullscreen(true).

On Windows (via ::SetWindowPos) and macOS (via [NSWindow toggleFullScreen:]), exiting fullscreen spins a native nested message loop. If an attacker closes the tab while this nested loop is running, the WebContents and its associated WebContentsUserData (including the PrintViewManager instance) are synchronously destroyed.

When the nested loop finishes, the stack unwinds back to PrintViewManager::OnRequestPrintPreviewCallback. The function then calls PrintPreviewAllowedForTesting() using the implicit this pointer. Because this is a raw pointer on the execution stack, it is not protected by MiraclePtr (BackupRefPtr). Since the object has been destroyed, this results in a virtual method call on a freed object, which can be exploited for Control-Flow Hijacking and Remote Code Execution (RCE) in the Browser Process.

Potential Steps to Trigger

1. An attacker-controlled renderer opens two tabs (Tab A and Tab B) in the same window.
2. In Tab A, the attacker uses JavaScript to enter HTML Fullscreen (document.documentElement.requestFullscreen()).
3. Tab A sends a mojom::PrintManagerHost::RequestPrintPreview IPC. The browser binds a WeakPtr and invokes PrintViewManager::OnRequestPrintPreviewCallback.
4. Inside the callback, the raw this pointer is extracted from the WeakPtr to execute the method. The code calls dialog_controller->PrintPreview().
5. The UI framework attempts to show the modal dialog, which triggers web_contents->ExitFullscreen(true).
6. The platform-specific ExitFullscreen implementation spins a nested message loop.
7. During the nested loop, Tab B sends a ClosePage IPC to close Tab A. Tab A’s WebContents and PrintViewManager are destroyed.
8. The attacker performs heap spraying (e.g., via other IPCs) to replace the freed PrintViewManager object in memory with a fake vtable.
9. The nested loop finishes. The stack unwinds.
   • Note: The code bypasses a CHECK in TabStripModel::SetTabBlocked during unwinding because Tab B is still open, keeping the stale tab index within bounds.
   • Note: The code bypasses a CHECK(weak_widget) in ShowWebModalDialogViews because the native dialog widget is closed asynchronously and still exists during the unwind.
10. Execution returns to OnRequestPrintPreviewCallback. The code calls PrintPreviewAllowedForTesting() on the freed this pointer.
11. The virtual call uses the attacker’s fake vtable. On Windows, Control Flow Guard (CFG) only verifies that the target is a valid function start, allowing the attacker to jump to an arbitrary ROP gadget and achieve RCE.

(Note: These are suggested steps based on code analysis; our tooling agent does not have the ability to run code to verify an exploit end-to-end.)

Suggested Fix

Unlike OnScriptedPrintPreviewCallback, which checks print_preview_state_ and explicitly handles ExitFullscreen with a WeakPtr guard, OnRequestPrintPreviewCallback lacks these protections.

The fix should guard the execution after PrintPreview() returns by checking if this is still valid. You can acquire a WeakPtr before the call and check it afterward:

  auto weak_this = weak_factory_.GetWeakPtr();
  dialog_controller->PrintPreview(web_contents(), *params);

  if (!weak_this) {
    return;
  }

  PrintPreviewAllowedForTesting();

Alternatively, verify print_preview_state_ before proceeding, similar to how OnScriptedPrintPreviewCallback operates.

Evaluated with Chrome root at commit: 65b3256311f3ab6fb9870eaa522de7e6dd2663bb

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.