CVE-2025-48541 AI-generated analysis

platform/packages/apps/Settings, biometrics/face (FaceSettings fragment)

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 (5 corrections). Verify against the commit before relying on it.

FaceSettings now only honours the hw_auth_token, sensor id, challenge and EXTRA_USER_ID intent extras when the activity's initial calling package is the Settings app itself; for any other (or unknown) caller it ignores them and uses the current user.

Root cause

In src/com/android/settings/biometrics/face/FaceSettings.java the fragment unconditionally read KEY_TOKEN ("hw_auth_token"), BiometricEnrollBase.EXTRA_KEY_SENSOR_ID, BiometricEnrollBase.EXTRA_KEY_CHALLENGE and Intent.EXTRA_USER_ID from the launching intent, without checking who launched it. The commit's test line (adb shell am start -a android.settings.FACE_SETTINGS --ei android.intent.extra.USER_ID 0, run from a user other than 0) shows that an external launch could make the face settings screen target a different user than the caller.

How the fix works

• FaceSettings.java, field declarations: mSensorId now defaults to -1 and mChallenge to 0 so that they hold safe values when the extras are not read (mToken stays null).
• FaceSettings.java, the initialization method that obtains mUserManager/mFaceManager/mDevicePolicyManager (hunk around line 176 in 14; method name not shown in the hunk header): the activity is obtained via requireActivity() cast to SettingsActivity and activity.getInitialCallingPackage() is compared to activity.getPackageName().
• If the calling package is null or differs from Settings' own package, only mUserId = UserHandle.myUserId() is set; the token, sensor id, challenge and EXTRA_USER_ID extras are never read.
• Only when the initial caller is Settings itself are the four extras read as before (mToken, mSensorId, mChallenge, mUserId with myUserId fallback).
• The rest of the flow (managed-profile check via mUserManager.getUserInfo(mUserId), controllers) is unchanged and now sees either the trusted values or the safe defaults.

Completeness

• Covers all four intent extras consumed by FaceSettings in this method (token, sensor id, challenge, user id) with one gate on the initial calling package.
• The gate relies on SettingsActivity.getInitialCallingPackage(); the diff does not show how that value is derived or whether it survives activity recreation, so correctness of the check depends on that helper (not shown).
• Only FaceSettings is changed; whether sibling biometric settings fragments read the same extras in the same way is not shown in the material.
• Single-commit fix; no tests added (Test: manual).

Behavior changes

• Launching android.settings.FACE_SETTINGS from any package other than Settings now ignores EXTRA_USER_ID and always targets the calling user (UserHandle.myUserId()).
• External callers can no longer supply hw_auth_token, EXTRA_KEY_SENSOR_ID or EXTRA_KEY_CHALLENGE; those fields stay null/-1/0 for such callers.
• Internal navigation from Settings to FaceSettings is unchanged.

Per major

• Android 14: same fix: f3cc1073e51e in android-security-14.0.0_r22 (cherry-pick, same Change-Id); 7/8 lines of the patched region present at android-security-14.0.0_r29.
• Android 15: same fix: aba2077a6c03 in android-security-15.0.0_r10; identical logic, only context differs (FeatureFactory.getFeatureFactory()); 7/8 lines present at android-security-15.0.0_r17.
• Android 16: same fix: 2aa27461a40b in android-security-16.0.0_r1; identical logic; 7/8 lines present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin); 7/8 lines of the patched region are present at android-security-17.0.0_r1.

Unknowns

• Implementation of SettingsActivity.getInitialCallingPackage() and how it is populated is not in the material.
• What a caller-supplied token, challenge or user id enabled downstream (e.g. in the remove/enroll controllers) is not shown; the bulletin only rates it High EoP.
• The name of the patched method is not shown in the hunk header.
• Whether other biometric settings fragments read the same extras unconditionally is not shown.
• Which line of the patched region is missing in the latest tags (7/8) is not shown.
• Any hardware requirement (e.g. a face sensor) for reaching the screen is not shown.

Back to September 2025 · Findings