0bb64e19da65dcd5b1738083f9c341b339111964  geolocation: Remove DanglingUntriaged from LocationProviderManager

The bug at a glance

This commit does not fix an exploitable use-after-free; it is a lifetime-audit outcome that removes a DanglingUntriaged suppression on non-ChromeOS platforms after concluding the pointed-to object outlives the holder there, while explicitly keeping the suppression on ChromeOS where a real teardown-order dangle is acknowledged but unresolved. The security value is diagnostic: it narrows Chromium’s dangling-pointer debt and pins a known ChromeOS shutdown-order dangle to a tracked bug. No web-reachable primitive is created or removed. Watch, not patch-now: it documents a latent lifetime concern rather than closing an attacker-usable one, and on the platform where a dangle may actually occur (ChromeOS) the annotation is deliberately retained.

LocationProviderManager holds a raw_ptr to a GeolocationSystemPermissionManager that was annotated DanglingUntriaged, meaning Chromium’s raw_ptr machinery had detected (or defensively suppressed) a possible dangling reference to it. After a lifetime audit, the author determined that on macOS and Windows the permission manager is a never-torn-down singleton whose lifetime always exceeds any LocationProviderManager, so the suppression is dead weight and is removed. On ChromeOS the audit found the opposite: the permission manager can be reset in Ash shutdown before LocationProviderManager is destroyed, so the suppression is kept and the underlying dangle is filed as crbug/474434915 for follow-up.

Root cause

The diff touches only a header declaration. Before the change, geolocation_system_permission_manager_ was declared unconditionally as const raw_ptr<GeolocationSystemPermissionManager, DanglingUntriaged>. The DanglingUntriaged trait tells Chromium’s MiraclePtr/raw_ptr instrumentation to tolerate this pointer becoming dangling (pointing at freed memory) without tripping the dangling-pointer detector; such annotations are triage debt applied in bulk and are expected to be removed once each site’s lifetime is proven safe or the real bug is fixed.

The patch splits the declaration by platform. Under BUILDFLAG(IS_CHROMEOS) it keeps the DanglingUntriaged variant and adds a comment plus TODO(crbug.com/474434915) recording that GeolocationSystemPermissionManager is reset in ChromeBrowserMainExtraPartsAsh::PostMainMessageLoopRun, which can run before LocationProviderManager is destroyed, creating a genuine dangling-pointer situation during process teardown. Under #else (macOS, Windows) it declares the pointer as a plain const raw_ptr<GeolocationSystemPermissionManager> with a comment stating the manager is never torn down and therefore outlives this, so the suppression is unnecessary.

The security-relevant substance is entirely in what the audit concluded, not in a behavioral change: no lifetime is altered, no ownership is changed, no callback is rebound. On non-ChromeOS the change simply re-enables the dangling-pointer detector for this member (a strengthening: a future regression that made this pointer dangle would now be caught rather than silently tolerated). On ChromeOS a real, acknowledged dangling access during shutdown remains suppressed. Because the dangle is confined to browser-process teardown of a device-service singleton and is not shown to be reachable or controllable from web content, it is a robustness/latent-safety issue rather than a demonstrated exploit primitive.

Key code

Platform split: DanglingUntriaged kept for ChromeOS (real teardown dangle), removed elsewhere

#if BUILDFLAG(IS_CHROMEOS)
  // TODO(crbug.com/474434915): Remove DanglingUntriaged for ChromeOS.
  const raw_ptr<GeolocationSystemPermissionManager, DanglingUntriaged>
      geolocation_system_permission_manager_;
#else
  // On macOS or Windows, `GeolocationSystemPermissionManager` is never torn
  // down, ensuring its lifetime exceeds that of `this` object.
  const raw_ptr<GeolocationSystemPermissionManager>
      geolocation_system_permission_manager_;
#endif

Patch walkthrough

• services/device/geolocation/location_provider_manager.h — Replaces the single unconditional DanglingUntriaged raw_ptr member with a #if BUILDFLAG(IS_CHROMEOS) split. ChromeOS keeps the suppression plus a documented TODO pointing at the Ash shutdown reset that can outlive the pointer; all other platforms drop the suppression, re-arming the dangling-pointer detector because the permission manager is a permanent singleton there. This is a declaration-only change with no runtime behavior difference besides which detector state applies per platform.

Background

raw_ptr / MiraclePtr — Chromium’s smart raw pointer that, in supported build modes, detects and can mitigate use-after-free by tracking whether the pointee has been freed. It is the default for pointer members and integrates with dangling-pointer detection at destruction time.

DanglingUntriaged — A raw_ptr trait that suppresses the dangling-pointer detector for a specific member. It was applied in bulk to un-triaged sites when detection was enabled; each occurrence is technical debt meant to be removed once the lifetime is proven safe or the real dangle is fixed.

GeolocationSystemPermissionManager — The device-service object that mediates OS-level location permission. On macOS/Windows it is created once and never destroyed; on ChromeOS it is owned by Ash and reset during PostMainMessageLoopRun shutdown.

Teardown-order dangle — A use-after-free that arises only from the order objects are destroyed at process shutdown. Such dangles are real but typically hard to weaponize because they occur during exit, not in response to attacker-timed web content.

Vulnerability window

1. Introduced — The member was annotated DanglingUntriaged in bulk when raw_ptr dangling detection was rolled out, without per-site lifetime analysis.
2. Investigated — A lifetime audit (motivated by ChromeOS test failures during shutdown) established that macOS/Windows never tear down the permission manager, while ChromeOS resets it in Ash’s PostMainMessageLoopRun before LocationProviderManager is destroyed.
3. Fixed / documented — Commit 0bb64e19da (Jan 22 2026, main@{#1573413}) removes the suppression on non-ChromeOS and keeps it on ChromeOS under TODO crbug/474434915; the ChromeOS dangle itself remains open.

Proof of concept

No test or PoC shipped, and none is applicable. The only acknowledged real dangle is a ChromeOS browser-process teardown-order issue (GeolocationSystemPermissionManager reset in Ash PostMainMessageLoopRun before LocationProviderManager destruction). Reproducing it means observing raw_ptr dangling detection fire during ChromeOS shutdown, not a web-triggerable action. No exploit is demonstrated and the commit does not claim exploitability.

Exploitation

1. Reach a dangling access — Only on ChromeOS, only during process teardown ordering, on an internal device-service singleton pointer. There is no shown web-content path to trigger or time this.
2. Control the freed object — Not demonstrated. The window is process exit; grooming the freed GeolocationSystemPermissionManager allocation from a renderer is not shown to be feasible.
3. Non-ChromeOS — No exploitation possible: the audit concludes the pointer never dangles there, and the patch re-enables detection to catch future regressions.

Detection & hunting

For defenders and detection engineers:

• raw_ptr dangling reports on ChromeOS shutdown — On dangling-pointer-detection builds, watch for reports naming geolocation_system_permission_manager_ / LocationProviderManager during ChromeBrowserMainExtraPartsAsh::PostMainMessageLoopRun; that is the acknowledged live dangle.
• Crash signatures at exit — Rare ChromeOS shutdown crashes touching services/device/geolocation during teardown are consistent with the unresolved teardown-order dangle.

Audit directions

• Remaining DanglingUntriaged members in services/device — Grep for raw_ptr<..., DanglingUntriaged> across services/device and geolocation; each is a candidate for the same audit-and-split treatment, especially members pointing at objects owned by Ash/BrowserMainParts that reset during shutdown.
• ChromeBrowserMainExtraPartsAsh::PostMainMessageLoopRun resets — Enumerate objects reset in Ash PostMainMessageLoopRun and cross-reference holders that outlive it (device service, keyed services) to find sibling teardown-order dangles.