CVE-2023-40076 AI-generated analysis

platform/frameworks/base, services/credentials (CredentialManagerUi, Credential Manager service)

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

The Credential Manager service (CredentialManagerUi) now creates the PendingIntent for its UI with PendingIntent.getActivityAsUser bound to UserHandle.of(mUserId) instead of PendingIntent.getActivity, which takes no explicit user.

Root cause

In services/credentials/java/com/android/server/credentials/CredentialManagerUi.java, the method that builds the Credential Manager UI intent (random UUID action, requestCode 0, FLAG_IMMUTABLE) returned PendingIntent.getActivity(mContext, 0, intent, FLAG_IMMUTABLE). That call does not tie the PendingIntent to the requesting user stored in the class field mUserId. The material does not show which user mContext resolves to. The bulletin rates the issue Critical, type ID (information disclosure); the material does not describe the disclosure path.

How the fix works

• Commit 9b68987df85b (one file, 5 insertions, 2 deletions) in CredentialManagerUi.java adds import android.os.UserHandle. It replaces PendingIntent.getActivity(mContext, /*requestCode=*/0, intent, PendingIntent.FLAG_IMMUTABLE) with PendingIntent.getActivityAsUser(mContext, /*requestCode=*/0, intent, PendingIntent.FLAG_IMMUTABLE, /*options=*/null, UserHandle.of(mUserId)).
• The explicit UserHandle makes the PendingIntent target the user stored in mUserId for this CredentialManagerUi instance. The request code, the random-UUID action and FLAG_IMMUTABLE are unchanged.

Completeness

• Covers the single PendingIntent creation site in CredentialManagerUi.java shown in the diff. The fix is one changed call plus an import.
• The existing TODO about creating a unique pending intent with a request code and cancelling pre-existing pending intents is left in place. requestCode stays 0, and uniqueness still relies only on the random UUID action.
• The material shows no other PendingIntent creation sites in the credentials service, so it cannot show whether sibling paths exist.

Behavior changes

• The Credential Manager UI PendingIntent is now created for UserHandle.of(mUserId). The fix adds no new error codes or validation failures.

Per major

• Android 14: same fix: resolved via commit 9b68987df85b in android-security-14.0.0_r3 (cherry-picked, Change-Id If03e146a069b9162d41eee26b7070ea52827fddf); 8/8 patched lines present at android-security-14.0.0_r29.
• Android 15: not affected (not listed by the bulletin); 8/8 patched lines present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin); 8/8 patched lines present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin); 8/8 patched lines present at android-security-17.0.0_r1.

Unknowns

• The diff hunk header does not show the name of the method that contains the changed PendingIntent call.
• Which user mContext resolves to, and so which user the PendingIntent targeted before the fix, is not shown.
• The material does not describe the information disclosure path that led to the Critical rating.
• The material does not show whether other PendingIntent creation sites exist in the credentials service.
• Whether releases older than 14 contain this code is not covered by the material.

Back to December 2023 · Findings