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: In WidgetBase::UpdateTextInputStateInternal, calling GetTextInputType() triggers a style and layout update via InputMethodController::TextInputType(). If this layout update causes synchronous frame detachment or widget destruction, execution continues on the freed WidgetBase instance and calls client_->FrameWidget() before the weak pointer check at line 1277. This leads to a potential use-after-free and virtual call dispatch through freed memory in the renderer process.

Affected files:

• third_party/blink/renderer/platform/widget/widget_base.cc

Estimated timestamp from git blame: 2020-06-19

Summary

In third_party/blink/renderer/platform/widget/widget_base.cc, WidgetBase::UpdateTextInputStateInternal invokes GetTextInputType() at line 1265, which can trigger a layout and style tree update (Document::UpdateStyleAndLayoutTree). If synchronous script execution or frame detachment occurs during this update and deletes the WidgetBase instance, UpdateTextInputStateInternal continues execution and accesses this->client_ at line 1269 before taking the weak_this liveness check at line 1277.

Root Cause Analysis

In third_party/blink/renderer/platform/widget/widget_base.cc:1256-1281:

void WidgetBase::UpdateTextInputStateInternal(bool show_virtual_keyboard,
                                              bool reply_to_request) {
  TRACE_EVENT0("renderer", "WidgetBase::UpdateTextInputStateInternal");
  if (ime_event_guard_) {
    DCHECK(!reply_to_request);
    if (show_virtual_keyboard)
      ime_event_guard_->set_show_virtual_keyboard(true);
    return;
  }
  ui::TextInputType new_type = GetTextInputType();   // [1] Calls layout-forcing method
  if (IsDateTimeInput(new_type))
    return;

  FrameWidget* frame_widget = client_->FrameWidget(); // [2] UAF: reads this->client_ on freed object

  blink::WebTextInputInfo new_info;
  ...
  if (frame_widget) {
    base::WeakPtr<WidgetBase> weak_this = weak_ptr_factory_.GetWeakPtr(); // [3] Guard placed too late
    new_info = frame_widget->TextInputInfo();
    if (!weak_this) {
      return;
    }

1. At [1] (widget_base.cc:1265), WidgetBase::GetTextInputType() forwards through client_->GetTextInputType() (web_frame_widget_impl.cc:3334) to InputMethodController::TextInputType() (third_party/blink/renderer/core/editing/ime/input_method_controller.cc:1976-2049). For focused editable elements (contenteditable), line 2044 explicitly executes GetDocument().UpdateStyleAndLayoutTree().
2. In Document::UpdateStyleAndLayoutTree (document.cc:2630-2670), PluginDisposeSuspendScope and ScriptForbiddenScope are used. When destructed at function exit, ~ScriptForbiddenScope runs before ~PluginDisposeSuspendScope, and deferred plugin disposals are invoked under ScriptForbiddenScope::AllowUserAgentScript (web_plugin_container_impl.cc:871).
3. If script execution or DOM tree mutations during this phase detach the local root frame or its parent (RemoteFrame::DetachChildren / LocalFrame::DetachImpl), WebFrameWidgetImpl::Close (web_frame_widget_impl.cc:538-580) calls widget_base_->Shutdown() and synchronously deletes the widget via widget_base_.reset() at line 574.
4. Because the calling function holds this as a raw stack pointer and no surviving raw_ptr<WidgetBase> holds a BackupRefPtr reference, WidgetBase is freed into PartitionAlloc immediately.
5. Control returns from GetTextInputType() to line 1269, where client_->FrameWidget() reads this->client_ from the freed memory chunk and executes a virtual method dispatch. The weak_this liveness check at line 1277 is reached only after this virtual call.

Potential Trigger Steps

(Note: These are suggested theoretical steps as our analysis tooling does not have runtime execution capabilities.)

1. Setup an outer page $A$ (Origin $X$) embedding a cross-origin iframe $B$ (Origin $Y$, remote in process $P$), which in turn embeds an iframe $C$ (Origin $X$, local root subframe in process $P$).
2. In frame $C$, create a contenteditable element and a plugin element (<embed>/<object>).
3. On user click or tap in frame $C$, handle the input event by focusing the contenteditable element and setting the plugin element to display: none.
4. When input processing triggers WidgetBase::ShowVirtualKeyboard() (widget_base_input_handler.cc:465) -> UpdateTextInputStateInternal(true, false):
   • GetTextInputType() at line 1265 forces UpdateStyleAndLayoutTree(), detaching the plugin’s layout object and queuing it for deferred disposal.
   • At scope exit, WebPluginContainerImpl::Dispose() calls Destroy().
   • The plugin teardown script removes iframe $B$ via window.top.document.getElementById('iframeB').remove().
   • Detaching $B$ synchronously detaches $C$, executing WebFrameWidgetImpl::Close -> widget_base_.reset().
5. When GetTextInputType() returns, line 1269 reads this->client_ and invokes virtual method FrameWidget() on the freed/reclaimed memory.

Suggested Fix

Capture a WeakPtr<WidgetBase> at the beginning of UpdateTextInputStateInternal before calling GetTextInputType(), and return immediately if the widget was destroyed:

void WidgetBase::UpdateTextInputStateInternal(bool show_virtual_keyboard,
                                              bool reply_to_request) {
  TRACE_EVENT0("renderer", "WidgetBase::UpdateTextInputStateInternal");
  if (ime_event_guard_) {
    DCHECK(!reply_to_request);
    if (show_virtual_keyboard)
      ime_event_guard_->set_show_virtual_keyboard(true);
    return;
  }
  base::WeakPtr<WidgetBase> weak_this = weak_ptr_factory_.GetWeakPtr();
  ui::TextInputType new_type = GetTextInputType();
  if (!weak_this || IsDateTimeInput(new_type))
    return;

  FrameWidget* frame_widget = client_->FrameWidget();
  ...
  if (frame_widget) {
    new_info = frame_widget->TextInputInfo();
    if (!weak_this) {
      return;
    }

Evaluated with Chrome root at commit: c6718ebbf2c677c6f63691e28c7801c563f6b19c

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.