CVE-2025-0078 AI-generated analysis

platform/frameworks/native, cmds/servicemanager (binder service manager)

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

servicemanager now calls setRequestingSid(true) on its own ServiceManager object before it registers itself as the "manager" service, so the flags on the self-registered object match the special flags used for the context object.

Root cause

In cmds/servicemanager/main.cpp main(), one ServiceManager instance (built with std::make_unique<Access>()) is registered as a normal service named "manager" through manager->addService("manager", manager, ...). The same instance is then made the binder context object (setTheContextObject, becomeContextManager). The commit message says servicemanager has special flags set to become a context object, but these were not set when it registers as itself. Before the fix, setRequestingSid(true) was not called on the object before self-registration.

How the fix works

• cmds/servicemanager/main.cpp:main(): one line is added, manager->setRequestingSid(true);. It comes right after sp<ServiceManager>::make(std::make_unique<Access>()) and before manager->addService("manager", manager, ...), so the ServiceManager binder is marked as requesting the caller SID when it registers itself.
• The following context-manager setup (setTheContextObject, becomeContextManager) is unchanged.

Completeness

• The fix covers the single self-registration point in main(). The same ServiceManager instance is used for addService("manager", ...) and for setTheContextObject.
• No change is made to the Access class or to how ServiceManager handles transactions that arrive without a SID. Whether such handling exists is not shown in the material.
• main() contains an #ifndef VENDORSERVICEMANAGER block, which suggests the same file is also built for vendorservicemanager. The build files are not in the material.

Behavior changes

• The ServiceManager binder object is marked as requesting the caller SID from before its self-registration as "manager". The commit message says the change was tested by booting with harsher checks.
• No new error codes or API changes appear in the diff.

Per major

• Android 14: same fix: commit 1114faa38da8 in android-security-14.0.0_r18 (cherry-pick of 5075f8244827), a one-line addition in cmds/servicemanager/main.cpp. 4/4 lines of the patched region are present at android-security-14.0.0_r29.
• Android 15: same fix: commit c32d4defe0f4 in android-security-15.0.0_r6, the same one-line addition. The surrounding context differs (a preceding disableBackgroundScheduling(true) line). 4/4 lines are present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin). The patched region is present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin). The patched region is present at android-security-17.0.0_r1.

Unknowns

• How ServiceManager/Access behaves when a transaction arrives without a security context (whether checks fail closed, fall back, or are skipped) is not shown.
• The material does not describe the concrete EoP consequence behind the bulletin rating beyond what the commit message says.
• Where the context-object 'special flags' named in the commit message are applied is not shown in the diff or context.
• Which callers can reach servicemanager through the self-registered "manager" object is not shown.

Back to March 2025 · Findings