CVE-2025-32328 AI-generated analysis

platform/frameworks/base, services/autofill (FillUi, DialogFillUi, SaveUi, Session, Helper)

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (6 corrections). Verify against the commit before relying on it.

The Autofill system UI (FillUi, DialogFillUi, SaveUi) now inflates service-supplied RemoteViews (and in SaveUi its whole UI) with a Context created for the current foreground user (new Helper.getUserContext) instead of the system_server user 0 context. Session also fetches the service's custom icon and label resources under a cleared Binder calling identity.

Root cause

FillUi, DialogFillUi and SaveUi built their Context as new ContextThemeWrapper(context, mThemeId) from the system_server context. FillUi and DialogFillUi passed it to RemoteViews.applyWithTheme for the presentations supplied by the autofill service in the FillResponse (main presentation, header, footer, per-dataset views, dialog presentations). SaveUi used it as the base context for its UI. system_server runs as user 0, so these views were inflated as user 0 rather than as the current foreground user. In FillUi a RemoteView URI permission check (a Helper method documented as checking against the current userId; failure throws 'Permission error accessing RemoteView') already existed, but the inflation that followed still used the user 0 context. Session.getServiceIcon and the service label lookup called PackageManager.getDrawable/getText on the master context without clearing the Binder calling identity.

How the fix works

• Helper.java: adds Helper.getUserContext(Context), annotated @RequiresPermission(INTERACT_ACROSS_USERS). It reads ActivityManager.getCurrentUser() and returns context.createContextAsUser(UserHandle.of(userId), 0), with a debug Slog when sDebug is set.
• FillUi.java, FillUi constructor: adds the field mUserContext = Helper.getUserContext(mContext) and uses it in the four RemoteViews.applyWithTheme calls (main response.getPresentation(), headerPresentation, footerPresentation, and the per-dataset presentation). Decor inflation via LayoutInflater.from(mContext) is unchanged. dump() prints mUserContext. The constructor gets @SuppressWarnings("AndroidFrameworkRequiresPermission").
• DialogFillUi.java, DialogFillUi constructor: adds mUserContext = Helper.getUserContext(mContext) and uses it in the three applyWithTheme calls (two presentation paths and the per-dataset presentation loop). Decor inflation still uses mContext. The same @SuppressWarnings is added.
• SaveUi.java, SaveUi constructor: the themed context is now new ContextThemeWrapper(Helper.getUserContext(context), mThemeId) { ... }. Everything the constructor inflates from that context, including R.layout.autofill_save via LayoutInflater.from(context), now uses the foreground user context. The same @SuppressWarnings is added.
• Session.java, getServiceIcon and the service label lookup: PackageManager.getDrawable(servicePackageName, iconResourceId, null) and getText(servicePackageName, customServiceNameId, null) are wrapped in Binder.clearCallingIdentity()/restoreCallingIdentity(token). The context used is still mService.getMaster().getContext().

Completeness

• All RemoteViews.applyWithTheme call sites shown in FillUi (4) and DialogFillUi (3) now use mUserContext. SaveUi switches its entire base context.
• The user id comes from ActivityManager.getCurrentUser() (the foreground user), not from the session's own user id.
• Session icon/label lookups: only the calling identity is cleared. The PackageManager lookup still uses the master service context. The material does not explain whether that is intended.
• FillUi and DialogFillUi keep the system context for their decor layout inflation. In SaveUi the decor layout is inflated with the user context.
• No other autofill UI surfaces appear in the diff. The material does not show whether other paths that render service-supplied views exist outside these three classes.

Behavior changes

• Service-supplied RemoteViews in the fill and dialog-fill UIs, and the whole save UI, are inflated with a Context for the current foreground user instead of user 0.
• Helper.getUserContext is annotated as requiring INTERACT_ACROSS_USERS. The callers suppress the AndroidFrameworkRequiresPermission lint with the comment 'System has all permissions'.
• New sDebug log line in Helper.getUserContext and a new 'mUserContext' line in FillUi.dump().
• FillResponse custom icon/label resource fetches in Session now run with the Binder calling identity cleared, and the identity is restored in a finally block.

Per major

• Android 14: same fix: platform/frameworks/base f08b9104a6e9 in android-security-14.0.0_r24 (RESTRICT AUTOMERGE cherry-pick, Change-Id I8a2c96259976e61d297dec914d10d86e585a6d6f). 8/8 patched lines present at android-security-14.0.0_r29.
• Android 15: same fix: platform/frameworks/base 3ca035e4cdf3 in android-security-15.0.0_r12. Same content, except that in FillUi mUserContext is assigned after mMaxInputLengthForAutofill. 8/8 lines present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin). The patched region (8/8 lines) is present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin). The patched region (8/8 lines) is present at android-security-17.0.0_r1.

Unknowns

• The exact impact of inflating as user 0 (which resources or URIs could be reached) is not shown. The bulletin only rates it High EoP.
• Why the Session icon/label lookups needed clearCallingIdentity (which caller identity was present) is not explained in the material.
• Whether Android 13, which the bulletin lists as affected, received a corresponding commit is not shown in the material.
• Which RemoteViews SaveUi inflates (for example custom descriptions) is not shown in the diff.
• Whether inline-suggestion rendering or other autofill UI code outside these three classes inflates service-supplied views is not shown.

Back to December 2025 · Findings