← Chrome — 2026-W31

8676797b54a82b2cf3604098600bc1f0799ac358  [M150] Fix potential use-after-free in WidgetBase.

severity high class UAF CVSS 7.3 signal score 12.7 AI review PLAUSIBLE
Structural signals: smartptr_member_added (+3.0), null_guard (+1.2), uaf_lifetime (+2.2), msg_strong (+3.0), msg_medium (+2.0), surgical (+1.3)

The bug at a glance

A use-after-free of the WidgetBase instance can occur when frame_widget->TextInputInfo() re-enters and destroys the widget, after which the method keeps using this; the path is web/IME reachable in the renderer, warranting high severity though the title calls it ‘potential’.

An attacker controlling page content can arrange for the synchronous side effects of a text-input-info query (IME/focus/editing events) to destroy the owning WidgetBase, so execution returns into a method that continues to touch freed member state.

Root cause

In WidgetBase’s text-input update path, frame_widget->TextInputInfo() can synchronously dispatch events (e.g. editing/focus/IME-driven script) that tear down the WidgetBase instance. Before the fix, the method continued to read and write members (last_vk_visibility_request and more) on the freed this after the call returned, a use-after-free. The fix captures a base::WeakPtr before the call and returns early if the weak pointer was invalidated, i.e. if the widget was destroyed during TextInputInfo().

Key code

Weak-ptr re-entrancy guard after TextInputInfo() may destroy this

if (frame_widget) {
  base::WeakPtr<WidgetBase> weak_this = weak_ptr_factory_.GetWeakPtr();
  new_info = frame_widget->TextInputInfo();
  if (!weak_this) {
    return;
  }

Patch walkthrough

  • third_party/blink/renderer/platform/widget/widget_base.cc — Takes a WeakPtr before calling frame_widget->TextInputInfo() and bails out if the widget was destroyed during that synchronous call, preventing subsequent member accesses on a freed WidgetBase. This is the classic re-entrancy/UAF guard pattern for a call that can reenter and destroy its caller.

Background

WidgetBase — Renderer-side base class backing a compositing/input widget for a frame or popup.

TextInputInfo() — Queries current text input state for IME/virtual-keyboard decisions and can synchronously run blink event handlers.

base::WeakPtr re-entrancy guard — Standard Chromium idiom to detect that ’this’ was destroyed during a nested call before touching members again.

Virtual keyboard (VK) policy — The affected code decides whether to show the on-screen keyboard based on the returned input info.

Vulnerability window

  1. Reachability — Page content focuses an editable element / drives IME so the renderer queries text input info.
  2. Trigger — TextInputInfo() synchronously dispatches an event whose handler destroys the WidgetBase (e.g. by removing the frame/widget) (inferred for the exact event).
  3. Primitive — Control returns into the method and it dereferences the freed WidgetBase this, a use-after-free.
  4. Escalation — Reclaiming the freed WidgetBase allocation could yield type confusion or a write primitive in the renderer (inferred).

Proof of concept

Conceptually: focus an editable region to trigger a text-input-state update, and from an IME/editing/focus event handler synchronously tear down the owning widget (e.g. detach the frame or close the popup) so the update method resumes on freed memory. No weaponized trigger is provided.

Exploitation

  1. Setup — Arrange editable content and an event handler that destroys the widget during input-state queries (inferred).
  2. Trigger — Cause the renderer to call TextInputInfo() so the handler fires and frees WidgetBase.
  3. Reclaim — Heap-spray to reoccupy the freed WidgetBase before the dangling access (inferred).
  4. Exploit — Turn the controlled use into memory disclosure or corruption toward renderer RCE (inferred).

Detection & hunting

For defenders and detection engineers:

  • weggli/grep for a member-returning call followed by member use without a WeakPtr guard — Hunt patterns ‘x = frame_widget->Foo(); … this->member’ where Foo() can run script, especially in widget/input code.
  • ASAN heap-use-after-free with WidgetBase in the free/use stacks during IME or focus changes — Fuzz focus/blur + IME + frame-detach interleavings under ASAN.

Audit directions

  • Other WidgetBase/FrameWidget methods calling into frame_widget-> that can run script — Verify each caller that continues to use this after such a call installs a WeakPtr (or GetWeakPtr) re-entrancy check.
  • Renderer input/IME paths querying editing state synchronously — Audit for destroy-during-callback hazards wherever a query can dispatch blink events.

Before / after

Loading diff…