CVE-2024-49728 AI-generated analysis

platform/packages/modules/Bluetooth, OPP (Object Push Profile) outbound share, android/app/src/com/android/bluetooth/opp/BluetoothOppSendFileInfo.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.

Adds a check in Bluetooth OPP's BluetoothOppSendFileInfo.generateFileInfo that rejects content URIs whose authority carries a user-id prefix for a user other than the current one. Such URIs now return SEND_FILE_INFO_ERROR and are not opened.

Root cause

BluetoothOppSendFileInfo.generateFileInfo went on to call contentResolver.getType and to query and open any content URI that passed the earlier checks. The tests mock contentResolverQuery and contentResolverOpenAssetFileDescriptor for this path. A content URI authority can carry a user id as user-info (for example "<id>@media"). Nothing checked that this user id matched the Bluetooth app's own user (UserHandle.myUserId()) before the provider was used.

How the fix works

• BluetoothOppSendFileInfo.java:generateFileInfo: after an existing early-return error check and before contentResolver.getType(uri), the fix adds `if (isContentUriForOtherUser(uri))`. On a match it logs an error with the URI and myUserId() and returns SEND_FILE_INFO_ERROR, so the URI is never queried or opened.
• BluetoothOppSendFileInfo.java:isContentUriForOtherUser (new private static helper): reads uri.getUserInfo() and returns true only when the user-info is non-empty and not string-equal to String.valueOf(myUserId()). URIs with no user-info, or with the current user's id, are allowed.
• On the Android 15 branch the same block also calls ContentProfileErrorReportUtils.report(BluetoothProfile.OPP, BluetoothProtoEnums.BLUETOOTH_OPP_SEND_FILE_INFO, BluetoothStatsLog.BLUETOOTH_CONTENT_PROFILE_ERROR_REPORTED__TYPE__LOG_ERROR, 15) and changes the file's 'Next tag value' comment from 15 to 16. The Android 14 backport does not include this metrics call.
• BluetoothOppSendFileInfoTest.java: adds three tests (other user returns SEND_FILE_INFO_ERROR; implicit user returns normal info; same user returns normal info). They use a new buildContentUriWithEncodedAuthority helper that builds content URIs with an encodedAuthority such as "<id>@media".

Completeness

• The check sits in generateFileInfo just before contentResolver.getType and only applies to URIs that explicitly put a user id in the authority. URIs with no user-info are treated as belonging to the current user.
• The comparison is a plain string equality against String.valueOf(myUserId()). Any non-empty user-info that does not match is rejected.
• The check runs before getType, query and openAssetFileDescriptor, so a rejected URI causes no provider interaction.
• This commit does not change any other OPP code path that may handle caller-supplied URIs. The material does not show whether any such path bypasses generateFileInfo.

Behavior changes

• generateFileInfo now returns SEND_FILE_INFO_ERROR for content URIs whose authority names a different user id.
• A new Log.e line "Uri: <uri> is invalid for user <id>" is written on rejection.
• Android 15 only: a ContentProfileErrorReportUtils error report with tag 15 is emitted on rejection.

Per major

• Android 14: adapted fix: commit 339d20053956 in android-security-14.0.0_r17 (RESTRICT AUTOMERGE backport). It has the same isContentUriForOtherUser check and tests, without the ContentProfileErrorReportUtils metrics call. 8/8 patched lines are present at android-security-14.0.0_r29.
• Android 15: same fix plus metrics: commit 4b65cbb339db ("Reapply ...") in android-security-15.0.0_r5 adds the check and a ContentProfileErrorReportUtils.report call with tag 15. 8/8 lines are present at android-security-15.0.0_r17.
• Android 16: not affected per the bulletin (not listed). The patched region (8/8 lines) is present at android-security-16.0.0_r8.
• Android 17: not affected per the bulletin (not listed). The patched region (8/8 lines) is present at android-security-17.0.0_r1.

Unknowns

• The material does not show which component or intent delivers the URI into generateFileInfo.
• The material does not show what the early-return check just before the insertion point validates.
• The material does not show whether the Bluetooth app could actually resolve or read another user's provider through such a URI.
• The Android 13 fix commit is not in the material, although the bulletin lists 13 as affected.
• The original Android 15 commit that 'Reapply' restores, and the reason it was reverted, are not shown.

Back to April 2025 · Findings