Medium watch CVSS 4.3 chrome Logic Error 📄 Reporter bug report 🔧 Commit mapped

Overview

Medium
Severity
4.3
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactInappropriate implementation in Toolbar
DescriptionInappropriate implementation in Toolbar
ComponentToolbar
Sub-componentUI>Browser>Mobile>Toolbar
Bug ClassLogic Error
Action tierwatch — logic/policy bug — security-relevant, no memory-unsafety
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Tracker461532432
Fix commit044d94f7f47f (chromium/src) +11/-9
CWECWE-1021
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
CISA KEVNot listed
CreditedKhalil Zhani
Reported2025-11-18 · bounty $2000 (per vendor advisory)
Fix landed2025-11-21 (public git)
Disclosed2025-12-10
Patch gap19 days — fix public in source before the advisory

Background

`BrowserControlsManager`
the Android Chrome class (chrome/android/java/.../fullscreen/BrowserControlsManager.java) that controls whether the top browser controls (the toolbar holding the URL/omnibox) are shown, hidden or scrollable, including on fullscreen entry and exit.
`BrowserControlsState`
the constraint enum for the controls: SHOWN (forced visible), HIDDEN (forced hidden) and BOTH (may scroll in and out).
`mForceRelayoutOnVisibilityChange`
a flag that makes the next visibility update force an Android view relayout, so the toolbar is actually redrawn rather than just marked View.VISIBLE.
`scheduleVisibilityUpdate`
schedules an update that applies the computed visibility to the Android controls view.

Root Cause Analysis

In a lambda inside BrowserControlsManager that reacts to a change in controls constraints (the hunk does not name the enclosing method), the forced relayout for the earlier bug crbug.com/452885338 was set only under narrow conditions. It sat inside an inner block that the hunk shows only partly. It also required BrowserControlsUtils.doSyncMinHeightWithTotalHeightV2() and getAndroidControlsVisibility() != View.VISIBLE. The commit message says that without a relayout on fullscreen exit, the toolbar view does not redraw even though it is VISIBLE and correctly positioned, and that this “can occur even when transitioning to the BOTH state”. Paths that missed the old condition could therefore leave the browser controls (including the URL display) invisible after leaving fullscreen.

The fix removes the feature-flag-gated block and adds a check after the inner block. Whenever the new constraints are SHOWN or BOTH and the Android controls are not VISIBLE, it sets mForceRelayoutOnVisibilityChange = true and calls scheduleVisibilityUpdate(). This widens the set of cases that force the redraw.

Key insight
The relayout that makes the toolbar actually redraw on fullscreen exit depended on a feature flag and a narrow code path, so some transitions back to a visible state left the toolbar hidden. The fix forces the relayout for every transition to SHOWN or BOTH while the controls are not visible.

Attack Path

  1. Enter fullscreen a web page enters fullscreen (for example through the Fullscreen API, which normally needs a user gesture), so the browser controls are hidden on Android.
  2. Exit fullscreen the page or user leaves fullscreen, and the controls constraints change to SHOWN or BOTH.
  3. Relayout skipped before the fix, if the transition did not hit the old inner branch or doSyncMinHeightWithTotalHeightV2() was off, no forced relayout happened, so the toolbar stayed undrawn even though it was logically visible.
  4. Spoofed browser UI with the real toolbar and URL not shown, the page has the whole screen and could draw fake browser UI or a fake URL (inferred).

Impact Assessment

On Chrome for Android, a web page can end up with the browser toolbar, including the security-relevant URL display, not drawn after a fullscreen exit, which enables UI or URL spoofing (inferred). The trigger is ordinary web content using fullscreen, which normally needs a user gesture to enter, plus device or timing conditions under which the visibility change does not redraw on its own. The commit message notes this as device-dependent for the earlier bug. The vendor rates it medium severity (“Inappropriate implementation in Toolbar”), and the advisory data given does not report exploitation in the wild.

Files Changed

  • chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java

Audit Directions

  • Security UI hidden after state transitions
    review fullscreen, picture-in-picture, keyboard, rotation and tab-switch transitions on Android for cases where the toolbar or URL bar is logically visible but never redrawn or laid out.
  • Security-relevant fixes behind feature flags
    look for redraw or visibility fixes that only apply when a feature such as doSyncMinHeightWithTotalHeightV2 is enabled, which leaves the default configuration exposed.
  • Visibility state vs. rendered state
    audit code that trusts View.getVisibility() (or the controls’ offset) as proof that the UI is on screen, and confirm a relayout or invalidate follows each change.
From 044d94f7f47fe37c0fea4556f89d336307f33e0a Mon Sep 17 00:00:00 2001
From: Patrick Noland <pnoland@google.com>
Date: Fri, 21 Nov 2025 14:42:42 -0800
Subject: [PATCH] Force relayout when constraints change to SHOWN or BOTH

The linked bug occurs due to not doing a relayout when exiting
fullscreen. Without the relayout, the view does not redraw despite being
VISIBLE and positioned in the correct location. This can occur even when
transitioning to the BOTH state.

Bug: 461532432
Change-Id: I3112a3d05c8ddaee2538d5e17880604f4374046c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7186537
Reviewed-by: Peilin Wang <peilinwang@google.com>
Commit-Queue: Patrick Noland <pnoland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1548734}
---

diff --git a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
index 243bc88..17554ad 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/fullscreen/BrowserControlsManager.java
@@ -243,21 +243,23 @@
                                     renderDrivenShowConstraint);
                         }
 
-                        // From https://crbug.com/452885338: Some devices when changing the top
-                        // controls visibility when exiting fullscreen, the visibility change might
-                        // not honor a redraw. We do this through forcing a relayout to avoid
-                        // the toolbar remains hidden.
-                        if (getAndroidControlsVisibility() != View.VISIBLE
-                                && BrowserControlsUtils.doSyncMinHeightWithTotalHeightV2()) {
-                            mForceRelayoutOnVisibilityChange = true;
-                        }
-
                         // If controls become locked, it's possible we've previously delayed
                         // actually setting visibility until a touch event is over. In this case, we
                         // need to trigger an update again now, which should go through due to
                         // constraints.
                         scheduleVisibilityUpdate();
                     }
+
+                    // From https://crbug.com/452885338, https://crbug.com/461532432: When changing
+                    // controls visibility when exiting fullscreen, the visibility change might not
+                    // honor a redraw. We do this through forcing a relayout to avoid the toolbar
+                    // remains hidden.
+                    if ((constraints == BrowserControlsState.SHOWN
+                                    || constraints == BrowserControlsState.BOTH)
+                            && getAndroidControlsVisibility() != View.VISIBLE) {
+                        mForceRelayoutOnVisibilityChange = true;
+                        scheduleVisibilityUpdate();
+                    }
                 });
     }
 
Loading diff…

Original Bug Report

reported by ch...@gmail.com

Bottom Minibar Fails to Display URL – Potential Phishing via Spoof Bar

Steps to reproduce the problem

  1. Go to https://lbstyle.github.io/testcase.html
  2. Tap inside the textarea field.
  3. Tap the button labeled “Go to google.com”.

Problem Description

Observed behavior: The spoof bar minibar does not display the current URL. This could allow a malicious page to overlay a fake minibar with a fake URL, potentially tricking users into entering sensitive information.

Summary

Bottom Minibar Fails to Display URL – Potential Phishing via Spoof Bar

Additional Data

Category: Security
Chrome Channel: Not sure
Regression: N/A \

View on issue tracker