CVE-2025-48618 AI-generated analysis
platform/frameworks/opt/telephony, CAT/SIM Toolkit proactive command decoding (com.android.internal.telephony.cat)
Adds a KeyguardManager.isDeviceLocked() check to CommandParamsFactory.processLaunchBrowser so that a SIM Toolkit LAUNCH BROWSER proactive command is rejected with a ResultException(ResultCode.LAUNCH_BROWSER_ERROR) while the device is locked. It also relaxes ResultException so this result code can be thrown with only a text explanation.
Root cause
CommandParamsFactory.processLaunchBrowser decoded every LAUNCH BROWSER proactive command it received, whether or not the device was locked. The resulting params went on to the STK app, which (per index search, StkAppService.launchBrowser in packages/apps/Stk) builds an ACTION_VIEW intent for the supplied URL or a default URL. Nothing in the decode path checked the keyguard state. In addition, ResultException's single-argument constructor listed LAUNCH_BROWSER_ERROR (0x26) as a code that requires additional info and threw an AssertionError without it. Throwing that code with only an explanation string would therefore have asserted.
How the fix works
- src/java/com/android/internal/telephony/cat/CommandParamsFactory.java: imports android.app.KeyguardManager and adds a private Context mContext field. The private CommandParamsFactory(RilMessageDecoder, IccFileHandler, Context) constructor stores its existing context parameter in this field.
- CommandParamsFactory.processLaunchBrowser: at the start of the method, before any TLV parsing, gets KeyguardManager via mContext.getSystemService(KeyguardManager.class). If it is non-null and isDeviceLocked() returns true, the method logs and throws new ResultException(ResultCode.LAUNCH_BROWSER_ERROR, "The device is locked, unable to process the command."), so decoding of the command stops.
- src/java/com/android/internal/telephony/cat/ResultException.java: ResultException(ResultCode) drops case LAUNCH_BROWSER_ERROR (0x26) from the switch that throws AssertionError when no additional info is given, and updates the ETSI TS 102 223 8.12 comment to match. This change is required because the two-argument constructor used by the new check calls this(result) before it sets mExplanation.
Completeness
- Only processLaunchBrowser gets the check. This commit changes no other proactive command handler in CommandParamsFactory.
- The lock state is checked at decode time in telephony, not when StkAppService.launchBrowser actually sends the ACTION_VIEW intent (per index search). The STK app side is unchanged.
- If getSystemService returns null for KeyguardManager, the check is skipped and the command is processed as before.
- KeyguardManager.isDeviceLocked() returns true only for a secured, locked device. A device with no secure lock set is not treated as locked by this API (general platform knowledge).
Behavior changes
- While the device is locked, decoding of LAUNCH BROWSER proactive commands now fails with a ResultException carrying ResultCode.LAUNCH_BROWSER_ERROR (0x26). The command does not continue to processing.
- New CatLog debug line: 'The device is locked, cannot launch the Browser'.
- ResultException can now be built with LAUNCH_BROWSER_ERROR and no numeric additional info without triggering an AssertionError.
Per major
- Android 14: same fix: commit cc7d88a59cbd in android-security-14.0.0_r24 (Change-Id I9f651c7f1c5674df5774f5a7609f6d3749b5c50c, cherry-picked from internal commit dcf5c112a93d). 8/8 patched lines present at android-security-14.0.0_r29.
- Android 15: same fix: commit 8e7b0146d56b in android-security-15.0.0_r12. Same hunks; only the surrounding context differs (the UUID and NPE_WHEN_CALLED_SEND_CMD_PARAMS_ERROR_MSG constants come before mContext). 8/8 lines present at android-security-15.0.0_r17.
- Android 16: same fix: commit fee68bcdcf02 in android-security-16.0.0_r3, identical to the Android 15 diff. 8/8 lines present at android-security-16.0.0_r8.
- Android 17: not affected (not listed by the bulletin). The patched region is present (8/8 lines) at android-security-17.0.0_r1.
Unknowns
- The material does not show the attacker model (who can inject the proactive command) or the concrete impact beyond the bulletin's High/EoP rating.
- How the thrown ResultException is handled downstream, including what terminal response is sent to the SIM, is not shown.
- The material does not show whether the STK app's existing user-confirmation handling for LAUNCH BROWSER played a part.
- The Android 13 fix is not shown.
- No automated test is included; the commit says it was verified manually with a test APK only.