CVE-2024-0048 AI-generated analysis

platform/frameworks/base, services/core accounts (AccountManagerService, system_server)

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.

Schedules a 15 minute MESSAGE_TIMED_OUT message for every AccountManagerService.Session at construction, so that a session still open at timeout runs onTimedOut(), which calls getResponseAndClose() and reports an error to the caller.

Root cause

The Session constructor registers each session in mSessions (mSessions.put(toString(), this)) and links to the response binder's death. AccountManagerService already had MESSAGE_TIMED_OUT, Session.cancelTimeout() and Session.onTimedOut(), but the constructor did not schedule a timeout. As a result, a session that did not complete had no time bound set at creation.

How the fix works

• services/core/java/com/android/server/accounts/AccountManagerService.java: adds the constant TIMEOUT_DELAY_MS = 1000 * 60 * 15 (15 minutes) next to the MESSAGE_TIMED_OUT definition.
• AccountManagerService.Session constructor: calls the new scheduleTimeout() after mSessions.put(toString(), this) and before linkToDeath on the response.
• AccountManagerService.Session.scheduleTimeout (new): sends mHandler.obtainMessage(MESSAGE_TIMED_OUT, this) with sendMessageDelayed(..., TIMEOUT_DELAY_MS). The existing cancelTimeout() removes these messages with removeMessages(MESSAGE_TIMED_OUT, this).
• AccountManagerService.Session.onTimedOut (existing): calls getResponseAndClose() and reports AccountManager.ERROR_CODE_REMOTE_EXCEPTION to the response. The fix only adds a verbose log line here.

Completeness

• Every Session object gets the timeout, because it is scheduled in the Session constructor.
• It only bounds how long a session lives. It does not limit how many sessions one caller can have outstanding within the 15 minute window.
• The actual cleanup depends on the existing onTimedOut/getResponseAndClose path, which the diff does not change. The material does not show that path's body or where cancelTimeout() is called on normal completion.
• The timeout is a hard-coded constant and cannot be configured.

Behavior changes

• An AccountManager session still open after 15 minutes is closed through Session.onTimedOut, and the client response receives onError(AccountManager.ERROR_CODE_REMOTE_EXCEPTION, ...).
• Authenticators that take longer than 15 minutes to answer will hit this timeout.
• New verbose log line 'Session.onTimedOut' under TAG when verbose logging is enabled.
• One additional delayed message per session is queued on mHandler.

Per major

• Android 14: same fix: commit 813900c458e9 (Merged-In Ib4cebf1750fc6324dc1c8853e0d716ea5e8ec073) in android-security-14.0.0_r6; all 8/8 patched lines are present at android-security-14.0.0_r29.
• Android 15: not affected (not listed by the bulletin); android-security-15.0.0_r17 contains the patched code (8/8 lines).
• Android 16: not affected (not listed by the bulletin); android-security-16.0.0_r8 contains the patched code (8/8 lines).
• Android 17: not affected (not listed by the bulletin); android-security-17.0.0_r1 contains the patched code (8/8 lines).

Unknowns

• The concrete trigger, and why Google rates the impact as EoP, are not in the material (bugs 303905130 and 316893159 are not included).
• Where cancelTimeout() is called on normal completion, the body of getResponseAndClose(), and how MessageHandler dispatches MESSAGE_TIMED_OUT are not in the material.
• Fix commits and status for Android 12, 12L and 13 (listed as affected by the bulletin) are not in the material.
• Whether anything scheduled MESSAGE_TIMED_OUT for sessions before this fix is not shown.

Back to March 2024 · Findings