CVE-2025-32346 AI-generated analysis
platform/packages/services/Telephony, Phone app voicemail settings (com.android.phone.settings.VoicemailSettingsActivity)
In VoicemailSettingsActivity.onActivityResult, the contact URI returned by a picker activity is now validated with ComponentCaller.checkContentUriPermission(FLAG_GRANT_READ_URI_PERMISSION) against the component that delivered the result, instead of only comparing the user ID encoded in the URI with the Phone app's own user ID; denial now logs an EventLog entry and throws SecurityException.
Root cause
VoicemailSettingsActivity.onActivityResult receives an Intent result containing a contact URI and queries it with getContentResolver().query(...) using the Phone app's own privileges. The only validation was `UserHandle.getUserId(Process.myUid()) != ContentProvider.getUserIdFromUri(data.getData(), currentUser)`, i.e. it checked whether the user ID embedded in the URI matched the current user. This does not verify that the component returning the result actually holds read access to that URI, so the Phone app could be made to read contact data (the commit's test steps reference a work profile contact) on behalf of a caller that has no such access.
How the fix works
- src/com/android/phone/settings/VoicemailSettingsActivity.java:onActivityResult: replaces the user-ID comparison with a caller permission check. It obtains `ComponentCaller currentCaller = getCurrentCaller()`; if null, logs an error and returns without querying.
- Same function: extracts `Uri contactUri = (data != null) ? data.getData() : null` and returns early with a warning if the Intent or URI is null (new explicit null handling).
- Same function: calls `currentCaller.checkContentUriPermission(contactUri, Intent.FLAG_GRANT_READ_URI_PERMISSION)`; on PackageManager.PERMISSION_DENIED it writes EventLog 0x534e4554 with tag 337785563 and the caller UID, then throws a SecurityException naming the caller uid/package and URI. Only when the check passes does the existing `getContentResolver().query(data.getData(), ...)` run.
- Imports updated: adds android.app.ComponentCaller, android.content.pm.PackageManager, android.net.Uri, android.util.EventLog; removes android.content.ContentProvider and android.os.Process.
Completeness
- Covers the contact-URI query in the patched hunk of VoicemailSettingsActivity.onActivityResult; the subsequent query still uses data.getData(), which is the same value as the validated contactUri.
- The check relies on getCurrentCaller() identifying the component that delivered the activity result; when it returns null the code logs an error and returns without querying (fail-closed).
- The check is for FLAG_GRANT_READ_URI_PERMISSION only, which matches the read-only query performed.
- No other onActivityResult or URI-handling paths in the Telephony project are touched by this commit; the material does not show whether similar patterns exist elsewhere.
Behavior changes
- A result whose caller lacks read permission on the returned URI now causes a SecurityException to be thrown from onActivityResult (previously a user-ID mismatch caused a silent return), plus an EventLog security event (0x534e4554 / 337785563).
- A null Intent or null URI now returns early with a warning log.
- Legitimate results from a picker that grants read URI permission are unaffected; results that merely carry a same-user URI without a permission grant are now rejected.
Per major
- Android 14: Not affected (not listed by the bulletin); at android-security-14.0.0_r29 the patched region is present (8/8 lines).
- Android 15: Not affected (not listed by the bulletin); at android-security-15.0.0_r17 the patched region is present (8/8 lines).
- Android 16: Resolved by commit ccfb4f0691ca in android-security-16.0.0_r1 (cherry-pick of 9eb57535ecb1 / 76467ce5606c); patched region present at android-security-16.0.0_r8.
- Android 17: Not affected (not listed by the bulletin); at android-security-17.0.0_r1 the patched region is present (8/8 lines).
Unknowns
- The material does not show the surrounding onActivityResult code (request code handling, how the picker is launched, any earlier null checks), so the exact entry conditions are inferred from the diff only.
- Whether the 8/8 presence reported for 14, 15 and 17 reflects an identical or an adapted commit, and which API levels provide ComponentCaller/getCurrentCaller on those branches, is not shown.
- The precise impact of the original flaw is not described in the material beyond the bulletin's EoP/High rating and the test steps mentioning a work profile contact.