CVE-2025-26464 AI-generated analysis

platform/packages/modules/AppSearch, AppSearchManagerService (system_server AppSearch service, app-function execution path)

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

Replaces the whole body of the hidden binder method AppSearchManagerService.executeAppFunction (AppSearch module, Android 15) with an unconditional UnsupportedOperationException. This disables the never-launched, flag-guarded app-function execution path in which, according to the commit, a security issue was reported.

Root cause

AppSearchManagerService exposed a binder method executeAppFunction(ExecuteAppFunctionAidlRequest, IAppSearchResultCallback). It verified the caller (verifyIncomingCallWithCallback, checkCallDenied, isUserOrganizationManaged, verifyExecuteAppFunctionCaller) and then dispatched executeAppFunctionUnchecked, which builds an AppFunctionService intent for the target package and resolves the service. The API was supposed to stay unreachable behind a feature flag that never launched. According to the commit, an attacker could still invoke the hidden API. The commit states that a security issue was reported in this path (EoP per the bulletin). The material does not identify the exact defect in the removed logic.

How the fix works

• service/java/com/android/server/appsearch/AppSearchManagerService.java:executeAppFunction (binder stub): the commit deletes the 76-line body and replaces it with a single `throw new UnsupportedOperationException("Moved to AppFunctionManager.")`. The deleted body held the null checks, caller verification, the CallStats logging callback, the organization-managed check, target package validation, verifyExecuteAppFunctionCaller, the executeLambdaForUserAsync -> executeAppFunctionUnchecked dispatch and rate-limit logging.
• The method now throws before it touches the request, so this binder entry point can no longer reach executeAppFunctionUnchecked. As a result, the service no longer resolves an AppFunctionService on a caller's behalf through this path.
• The new comment gives the reasons: the flag never launched, a hidden-API path to the method existed, and since Android 16 the API lives in AppFunctionManager.

Completeness

• Disables the executeAppFunction binder entry point in AppSearchManagerService unconditionally, whatever the flag state, caller identity or user.
• executeAppFunctionUnchecked is still in the file at android-security-15.0.0_r17 (lines 2305-2320); the fix does not delete it. The diff shows no other caller of it, but the material does not prove that none exists.
• The fix removes the path instead of correcting it. Other code with similar logic, such as frameworks/base AppFunctionManagerServiceImpl.executeAppFunctionInternal (per index search), is not touched by this commit. The material does not show whether that code shares the defect.
• The commit changes only AppSearchManagerService.java; client-side AppSearch classes are not modified by it.

Behavior changes

• Any call to executeAppFunction now throws UnsupportedOperationException in the service. The IAppSearchResultCallback is never invoked. Before the fix, failures were reported through the callback as AppSearchResult codes (RESULT_SECURITY_ERROR, RESULT_INVALID_ARGUMENT, RESULT_RATE_LIMITED).
• The material does not show whether the calling process receives the exception; that depends on whether the AIDL method is oneway.
• This method no longer logs a CallStats entry with CALL_TYPE_EXECUTE_APP_FUNCTION, and caller verification and rate limiting for this call type no longer run.
• No AppFunctionService is resolved through this path any more.

Per major

• Android 14: Not affected per the bulletin. 5/8 lines of the patched region are present at android-security-14.0.0_r29. The material does not show whether the executeAppFunction method exists in the Android 14 source.
• Android 15: Same fix: commit e272ad005292 in android-security-15.0.0_r9 (cherry-pick of b1d2fcc8b39b, Change-Id Ia5bf6a6133aac5f83c5ec062ccd25662bd29a8b0). All 8/8 lines of the throwing stub are present at android-security-15.0.0_r17.
• Android 16: Not affected per the bulletin. 6/8 lines of the patched region are present at android-security-16.0.0_r8. The commit says the code was already removed in main and that the API moved to AppFunctionManager in Android 16. The material does not show which lines match on this branch.
• Android 17: Not affected per the bulletin. 6/8 lines of the patched region are present at android-security-17.0.0_r1. The material does not show which lines match.

Unknowns

• The specific defect in the removed verification/dispatch logic that made up the EoP; the commit only says a security issue was reported in the code path.
• Whether executeAppFunctionUnchecked or verifyExecuteAppFunctionCaller still have callers, or still exist, after the fix.
• Whether the IAppSearchManager.executeAppFunction AIDL method is oneway, which decides whether callers see the exception.
• Whether the client-side framework AppSearch classes were changed in a separate commit for Android 15.
• Whether the separate AppFunctionManagerServiceImpl path in frameworks/base (per index search) has any of the same logic or defect.
• Which lines of the patched region match on Android 14, 16 and 17.

Back to September 2025 · Findings