CVE-2024-23707 AI-generated analysis

platform/packages/apps/Settings, search (SearchResultTrampoline / SearchFeatureProviderImpl)

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.

SearchResultTrampoline in Settings now identifies the caller of its authorization check with Activity.getLaunchedFromPackage() instead of getCallingActivity(), and SearchFeatureProvider.verifyLaunchSearchResultPageCaller is changed to take the launching package name as a String.

Root cause

SearchResultTrampoline.onCreate() called getCallingActivity() and passed the resulting ComponentName to SearchFeatureProviderImpl.verifyLaunchSearchResultPageCaller(). That method allowed the launch only if the package name was the Settings package, the SettingsIntelligence package (getSettingsIntelligencePkgName), or signature-allowlisted (isSignatureAllowlisted). The same ComponentName also drove isSettingsIntelligence(), which selects the launch path for the result page. Per the commit message, getCallingActivity() reports who will get the result of the Activity, not who launched it, so the identity the check relied on did not reliably reflect the launching package. getLaunchedFromPackage() reports who launched the Activity or built the PendingIntent used to launch it.

How the fix works

• src/com/android/settings/search/SearchResultTrampoline.java:onCreate - replaces `final ComponentName callingActivity = getCallingActivity();` with `final String callerPackage = getLaunchedFromPackage();` and passes callerPackage to verifyLaunchSearchResultPageCaller(this, callerPackage) and to isSettingsIntelligence(callerPackage). The ComponentName import is dropped.
• src/com/android/settings/search/SearchResultTrampoline.java:isSettingsIntelligence - signature changed from (ComponentName callingActivity) to (String callerPackage). It is now simply TextUtils.equals(callerPackage, getSettingsIntelligencePkgName(this)), with the null check removed (TextUtils.equals handles null).
• src/com/android/settings/search/SearchFeatureProvider.java:verifyLaunchSearchResultPageCaller - interface signature changed to (@NonNull Context context, @NonNull String callerPackage).
• src/com/android/settings/search/SearchFeatureProviderImpl.java:verifyLaunchSearchResultPageCaller - takes the String callerPackage and throws IllegalArgumentException when TextUtils.isEmpty(callerPackage) (previously when the ComponentName was null). isSettingsPackage and isAllowlistedPackage are computed directly from callerPackage. Otherwise unchanged (SecurityException for non-allowed callers). The unused TAG constant and the ComponentName import are removed.
• tests/robotests/src/com/android/settings/search/SearchFeatureProviderImplTest.java - the three verifyLaunchSearchResultPageCaller tests (badCaller_shouldCrash, settingsCaller_shouldNotCrash, settingsIntelligenceCaller_shouldNotCrash) are updated to pass package name Strings.

Completeness

• The fix covers both uses of the caller identity in SearchResultTrampoline: the privilege gate (verifyLaunchSearchResultPageCaller) and the launch-path selection (isSettingsIntelligence). This commit touches no other getCallingActivity() call sites in Settings, and the material does not show whether any exist.
• The allow decision logic itself (Settings package, SettingsIntelligence package, isSignatureAllowlisted) is unchanged; only the source of the identity changes.
• Per the commit message, getLaunchedFromPackage() also reports the creator of a PendingIntent used to launch the activity, so a launch through a PendingIntent built by an allowed package is accepted. The material does not show whether any such PendingIntent exists.
• The IllegalArgumentException message still says 'must be called with startActivityForResult', which no longer matches the new check (empty launching package).

Behavior changes

• The caller identity for the trampoline is now the launching package (or PendingIntent creator) instead of the result-receiving component. Allowed packages no longer need to use startActivityForResult to pass the check, and non-allowed launching packages receive a SecurityException.
• IllegalArgumentException is now thrown when getLaunchedFromPackage() returns null or empty, instead of when getCallingActivity() returned null.
• isSettingsIntelligence() now compares the launching package String instead of the result receiver's package, so the embedded-activity launch path is chosen based on the launching package.
• The SearchFeatureProvider.verifyLaunchSearchResultPageCaller interface signature changed (ComponentName to String), which breaks any out-of-tree implementations or callers of the old signature.

Per major

• Android 14: same fix: commit f1d0079c9173 (cherry-pick of 901880a1d2e6, Change-Id If97018c2741caef622f0596bbfeaa42ef1788b78) in android-security-14.0.0_r8. At android-security-14.0.0_r29, 7/8 lines of the patched region are present; the context shows the String-based interface and the SearchFeatureProviderImpl check.
• Android 15: not affected per the bulletin; at android-security-15.0.0_r17, 7/8 lines of the patched region are present.
• Android 16: not affected per the bulletin; at android-security-16.0.0_r8, 7/8 lines of the patched region are present.
• Android 17: not affected per the bulletin; at android-security-17.0.0_r1, 7/8 lines of the patched region are present.

Unknowns

• The material does not show the AndroidManifest declaration of SearchResultTrampoline (exported status, intent filters, permissions).
• The material does not show which line of the 8-line patched region differs in the latest security tags, or why.
• The material does not show, beyond the EoP rating, what a non-allowed caller could reach through the trampoline (which Settings pages or extras).
• The material does not show whether other Settings activities use getCallingActivity() for authorization.

Back to May 2024 · Findings