CVE-2023-45774 AI-generated analysis
platform/frameworks/base, ShortcutService (services/core/java/com/android/server/pm/ShortcutService.java)
ShortcutService now checks, while validating an incoming shortcut, that the calling UID can grant read access to the content URI behind a URI-based shortcut icon (Icon.TYPE_URI / TYPE_URI_ADAPTIVE_BITMAP), using UriGrantsManagerInternal.checkGrantUriPermission.
Root cause
In ShortcutService.java, the incoming-shortcut validation method patched by the hunk (it comes before fixUpIncomingShortcutInfo(ShortcutInfo, boolean)) called only ShortcutInfo.validateIcon(shortcut.getIcon()) on the icon. For icons of type Icon.TYPE_URI or Icon.TYPE_URI_ADAPTIVE_BITMAP, nothing checked that the calling UID had read access to the referenced content URI. The bulletin rates this High / EoP.
How the fix works
- services/core/java/com/android/server/pm/ShortcutService.java: in the validation method just before fixUpIncomingShortcutInfo(ShortcutInfo, boolean) (its name is not shown in the diff), a call to validateIconURI(shortcut) is added after ShortcutInfo.validateIcon(shortcut.getIcon()), inside the `if (shortcut.getIcon() != null)` block.
- New private method ShortcutService.validateIconURI(ShortcutInfo si): gets callingUid from injectBinderCallingUid(); returns early if the icon is null or is neither TYPE_URI nor TYPE_URI_ADAPTIVE_BITMAP; otherwise calls mUriGrantsManagerInternal.checkGrantUriPermission(callingUid, si.getPackage(), ContentProvider.getUriWithoutUserId(uri), Intent.FLAG_GRANT_READ_URI_PERMISSION, ContentProvider.getUserIdFromUri(uri, UserHandle.getUserId(callingUid))). The user id embedded in the URI is used, defaulting to the caller's user. Only READ is checked.
- Adds import android.content.ContentProvider. The diff adds no field: mUriGrantsManagerInternal already exists in ShortcutService.
Completeness
- Covers both URI icon types (TYPE_URI and TYPE_URI_ADAPTIVE_BITMAP) for shortcuts that pass through the patched validation method. Which ShortcutService entry points reach that method is not shown.
- Validates only at ingestion time, against the binder calling UID. The material does not show where the stored URI is later resolved, or whether a check exists there.
- Only Intent.FLAG_GRANT_READ_URI_PERMISSION is checked.
Behavior changes
- Publishing or updating a shortcut with a URI-based icon now goes through a UriGrantsManagerInternal.checkGrantUriPermission check for the calling UID. Shortcuts whose caller lacks access to the URI should be rejected. The exact failure seen by the caller is not shown.
- The check uses the user id embedded in the URI (defaulting to the caller's user) and the shortcut's package (si.getPackage()) as the target package.
Per major
- Android 14: same fix: commit 1332ecd5e322 in android-security-14.0.0_r3 (cherry-pick, Change-Id I392f8e923923bf40827a2b6207c4eaa262694fbc); at android-security-14.0.0_r29 all 8/8 lines of the patched region are present.
- Android 15: not affected per the bulletin; the patched region is present (8/8 lines) at android-security-15.0.0_r17.
- Android 16: not affected per the bulletin; the patched region is present (8/8 lines) at android-security-16.0.0_r8.
- Android 17: not affected per the bulletin; the patched region is present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- Which component later loads the stored URI icon and what it exposes; the consumer side is not shown.
- The name of the enclosing method of the patched hunk, and which ShortcutService entry points (publish, update, pin request) reach it.
- Whether URI icons can enter by other routes (for example persisted state or manifest shortcuts) that bypass this validation.
- The exact failure mode a caller sees when the check fails.
- Status of the fix on Android 11, 12, 12L and 13 (listed as affected); no per-major facts are given for them.