CVE-2025-48591 AI-generated analysis

platform/frameworks/base, MMS system service broker (services/core MmsServiceBroker, mms/java IMms.aidl and MmsManager)

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

Adds a callingUser parameter to the IMms binder interface and makes MmsServiceBroker fill it from Binder.getCallingUserHandle(), so MmsService can check that the client-supplied contentUri belongs to the originating user.

Root cause

MmsServiceBroker in system_server takes sendMessage, downloadMessage, importMultimediaMessage and addMultimediaMessageDraft calls from apps and forwards them over IMms to MmsService. The forwarded call carried subId, callingPkg and the app-supplied contentUri but not the originating caller's user ID. MmsService therefore had nothing to check contentUri against for the originating user. The commit message says the goal is to 'Convey the originating user ID across the nested binder calls to MMSService to validate the contentURI is coming from the same userId'.

How the fix works

• mms/java/com/android/internal/telephony/IMms.aidl: adds an 'in int callingUser' parameter to sendMessage, downloadMessage, importMultimediaMessage and addMultimediaMessageDraft, documented as 'user id of the calling app'. Other IMms methods are unchanged.
• services/core/java/com/android/server/MmsServiceBroker.java (BinderService): the four proxied methods accept the new callingUser argument but do not use it. When forwarding to getServiceGuarded(), they pass getCallingUserId() instead. This is a new private helper that returns Binder.getCallingUserHandle().getIdentifier(). The user ID therefore comes from the binder identity of the actual caller, so a client cannot supply a different one.
• services/core/java/com/android/server/MmsServiceBroker.java (mServiceStubForFailure): the four stub methods get the new signatures. Their behaviour is unchanged (they return an error PendingIntent or null).
• mms/java/android/telephony/MmsManager.java: sendMessage and downloadMessage pass UserHandle.USER_NULL as a placeholder callingUser. The broker overwrites it.
• The actual contentUri-vs-user check is done on the MmsService side (the IMms implementer), which is not part of this commit. This change only passes along the information that check needs.

Completeness

• Covers four IMms methods that take a caller-supplied contentUri: sendMessage, downloadMessage, importMultimediaMessage and addMultimediaMessageDraft.
• The broker takes the user ID from Binder.getCallingUserHandle(), so the placeholder value the client provides cannot influence it.
• Other IMms methods are not changed. deleteStoredMessage (callingPkg, messageUri) is shown taking a URI and gets no callingUser. The material does not show whether it or the other methods needed one.
• The enforcement itself (comparing callingUser with the owner of contentUri) happens in MmsService, which the material does not show. This commit alone adds no validation.

Behavior changes

• The IMms binder transaction layout changes for four methods (one new int parameter), so the IMms clients (MmsManager and the broker) and the implementer (MmsService) must be updated together.
• MmsService receives the originating user ID for these four calls. Any rejection based on it would show up through the usual MMS failure paths. This commit introduces no new error codes.

Per major

• Android 13: Listed as affected by the bulletin. The material includes no Android 13 commit, so its status is unknown.
• Android 14: Same fix: platform/frameworks/base 1dd5a8353b99 in android-security-14.0.0_r24 (Change-Id I9beb19f1a94aae76e6cd48a72feeb6c1dc47cf5a). 7 of 8 lines of the patched region are present at android-security-14.0.0_r29.
• Android 15: Same fix: platform/frameworks/base eba8dce96baa in android-security-15.0.0_r12. The diff is identical apart from line offsets in MmsServiceBroker.java. 7 of 8 lines of the patched region are present at android-security-15.0.0_r17.
• Android 16: Not affected (not listed by the bulletin). 7 of 8 lines of the patched region are present at android-security-16.0.0_r8.
• Android 17: Not affected (not listed by the bulletin). 7 of 8 lines of the patched region are present at android-security-17.0.0_r1.

Unknowns

• The material does not include the MmsService-side change that uses callingUser to validate contentUri, so the exact check and how it fails are unknown.
• MmsService's project location and how it is versioned against frameworks/base are not shown.
• The bulletin lists Android 13 as affected, but no Android 13 commit is provided.
• The material does not show whether other IMms methods that carry URIs (for example deleteStoredMessage) needed similar treatment.

Back to December 2025 · Findings