CVE-2025-48522 AI-generated analysis

platform/frameworks/base, CompanionDeviceManager (core/java/android/companion/AssociationRequest.java)

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.

AssociationRequest.Builder.setDisplayName now rejects display names longer than 1024 characters with an IllegalArgumentException. Before, it accepted an app-supplied string of any length, and that string is shown in the CompanionDeviceManager confirmation UI.

Root cause

AssociationRequest.Builder.setDisplayName only called requireNonNull on the caller-supplied CharSequence and stored it with no length limit. The class javadoc in the code context describes this display name as "the Display name of the device to be shown in the CDM confirmation UI" and says it must be non-null for self-managed associations. An application could therefore pass a display name of any length into an association request that the system shows to the user. The bulletin rates the issue as a High severity EoP. The material does not show what the oversized name actually causes downstream.

How the fix works

• core/java/android/companion/AssociationRequest.java: adds a class constant DISPLAY_NAME_LENGTH_LIMIT = 1024.
• core/java/android/companion/AssociationRequest.java:Builder.setDisplayName: after checkNotUsed() and mDisplayName = requireNonNull(displayName), throws IllegalArgumentException("Length of the display name must be at most 1024 characters") when displayName.length() > DISPLAY_NAME_LENGTH_LIMIT. The assignment to mDisplayName happens before the check, so the Builder field still holds the oversized value when the exception is thrown.
• Single-commit fix that touches only this one file.

Completeness

• Covers only the public Builder.setDisplayName path.
• mDisplayName is assigned before the length check. The material does not show build(), so it is not shown whether a caller that catches the exception could still build a request carrying the oversized value.
• The private AssociationRequest constructor (line 257 in the context) takes @Nullable CharSequence displayName with no length check, and the class implements Parcelable. The material does not show whether the unparceling path re-validates the length, so as shown the check runs only in the Builder.
• No change to the system-side CDM service or to the confirmation UI that consumes the display name.

Behavior changes

• AssociationRequest.Builder.setDisplayName throws IllegalArgumentException for CharSequence inputs longer than 1024 characters. Before the fix, any length was accepted. Apps that pass longer names will get the exception from setDisplayName unless they catch it.

Per major

• Android 14: same fix: aa93bf9db684 in android-security-14.0.0_r22. 4/4 lines of the patched region present at android-security-14.0.0_r29.
• Android 15: same fix: bdad29b85a6c in android-security-15.0.0_r10, identical diff with the same file index as 14. 4/4 lines present at android-security-15.0.0_r17.
• Android 16: same fix: eb3cf182f929 in android-security-16.0.0_r1. Same logic at different line offsets: the constant sits before the device icon field (around line 274) and the check is around line 503. 4/4 lines present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin). 3/4 lines of the patched region present at android-security-17.0.0_r1.

Unknowns

• What an oversized display name actually caused in the CDM UI or service (why this was an EoP) is not shown in the material.
• Whether AssociationRequest's Parcelable CREATOR, the private constructor path or build() enforces the same 1024-character limit is not shown.
• Whether a Builder that keeps an oversized mDisplayName after a caught exception can still produce a request is not shown.
• Why 1024 was chosen, and whether a CTS test was added, are not in the material.

Back to September 2025 · Findings