{ "month": "2024-09", "generated": "2026-10-06T12:05+00:00", "majors": { "14": { "counts": { "announced": 10, "certain": 10, "probable": 0, "not_published": 0, "not_covered": 0, "awaiting": 0 }, "advisories": [ { "cve": "CVE-2024-32896", "osv_id": "ASB-A-324321147", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "RecoverySystemService.rebootRecoveryWithCommand() now destroys all KeyMint keys via the new AndroidKeyStoreMaintenance.deleteAllKeys() (IKeystoreMaintenance.deleteAllKeys) before rebooting to recovery when the command contains \"--wipe_data\", with a matching SELinux allow for system_server, so FBE-encrypted data becomes unrecoverable even if the recovery data wipe is interrupted or skipped.", "confidence": "high", "backport_notes": [ "Apply the sepolicy change (delete_all_keys in allow system_server keystore:keystore2, in both private/system_server.te and the matching prebuilts/api//private/system_server.te) together with the frameworks/base change; otherwise the deleteAllKeys() call can be expected to fail and would only be logged via Log.wtf. The Java side depends on IKeystoreMaintenance.deleteAllKeys() in the android.security.maintenance AIDL and on com.android.server.utils.Slogf.", "The Android 15 entry points to a soong change whose content does not match this fix. To verify, look directly for RECOVERY_WIPE_DATA_COMMAND / deleteSecrets() in RecoverySystemService and deleteAllKeys() in AndroidKeyStoreMaintenance." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 5, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/frameworks/base", "sha": "8b7b2c66ca96d711fb364cbcc9d655197d9743e0", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null }, { "project": "platform/system/sepolicy", "sha": "92cbf8d4f18ccb2c488f50b7300bd6bfc33023aa", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 2, "projects": [ "platform/frameworks/base", "platform/system/sepolicy" ] }, { "cve": "CVE-2024-40650", "osv_id": "ASB-A-293199910", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "Adds android:maxLength=500 to the wifi_item_edit_content style in Settings res/values/styles.xml, so edit fields using that style (the commit tests it on \"Add network\") accept at most 500 characters.", "confidence": "medium", "backport_notes": [ "Pure resource change: add 500 inside the wifi_item_edit_content style in res/values/styles.xml. On forks where the Wi-Fi edit fields use a different or renamed style, apply the attribute to the style or layout those fields actually use." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 7, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "2968ccc911956fa5813a9a6a5e5c8970e383a60f", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40652", "osv_id": "ASB-A-327749022", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "SettingsHomepageActivity.onCreate now reads Settings.Global.DEVICE_PROVISIONED and immediately finishes the activity when the device is not yet provisioned, so the Settings homepage cannot be used before setup completes.", "confidence": "high", "backport_notes": [ "Single-file, self-contained change with no new dependencies; prefer the Android 14 form (finish() followed by return) so no further onCreate initialization runs on an unprovisioned device." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 2, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "2909433f7d59dcdd0c74044b1c8e9f48927193dc", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40654", "osv_id": "ASB-A-333364513", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "SearchResultTrampoline now identifies its launcher with getLaunchedFromPackage() instead of getCallingActivity(), and SearchFeatureProvider.verifyLaunchSearchResultPageCaller now takes the launching package name instead of the result-receiving ComponentName.", "confidence": "high", "backport_notes": [ "Single commit, but it changes the SearchFeatureProvider interface. Update every implementation (including any OEM FeatureFactory override) and the robotests together, or the build breaks.", "The SearchResultTrampoline hunk touches the activity-embedding / isSettingsIntelligence branch, and that code differs between branches (see the Android 15 merge diff), so check that hunk by hand." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "change_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r8", "date": "2024-05-06", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r8", "date": "2024-05-06", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "f1d0079c91734168c150f839168544f407b17b06", "tag": "android-security-14.0.0_r8", "provenance": "security_tag", "method": "change_id", "confidence": "certain", "evidence": "ref f1d0079c9173", "similarity": null } ], "n_public_commits": 1, "public_before_announcement_days": 118, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40655", "osv_id": "ASB-A-300904123", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "Adds an unbindService() call to the call-screening timeout handler in Telecom's CallScreeningServiceHelper so that a CallScreeningService that never responds is released after the timeout instead of staying bound.", "confidence": "high", "backport_notes": [ "The change is self-contained. Insert mContext.unbindService(serviceConnection) after mFuture.complete(null) in the postDelayed timeout lambda of CallScreeningServiceHelper.bindAndGetCallIdentification, and add a catch for IllegalArgumentException before the existing finally { Log.endSession(); }. The Log.i(Object, String, Object...) form is used. On older trees, verify that this overload exists or use the Log.w(TAG, ...) form already present in the same block." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 4, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/services/Telecomm", "sha": "eeef54b37a362f506ea3aa155baddc545b6a909a", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/services/Telecomm" ] }, { "cve": "CVE-2024-40656", "osv_id": "ASB-A-329058967", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "ID" ], "status": "resolved", "brief": { "summary": "Adds a cross-user validation of the StatusHints icon carried by a ParcelableConference in ConnectionServiceWrapper's handleCreateConferenceComplete callback. It uses the Binder calling user, captured before the calling identity is cleared.", "confidence": "high", "backport_notes": [ "The fix calls StatusHints.validateAccountIconUserBoundary(Icon, UserHandle), so confirm that this helper exists on the target branch. The 14 and 15 hunks are identical apart from line offsets." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/services/Telecomm", "sha": "f3e6a6c02439401eb7aeb3749ee5ec0b51a625b9", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/services/Telecomm" ] }, { "cve": "CVE-2024-40657", "osv_id": "ASB-A-341886134", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "Settings' AccountTypePreferenceLoader now neutralizes clicks on any preference inflated from an external account authenticator's accountPreferences XML whose android:fragment is not already present in the host preference group, so that external apps cannot have Settings open its internal fragments.", "confidence": "high", "backport_notes": [ "This is a single self-contained commit that adds androidx.annotation, androidx.collection.ArraySet and java.util.Set imports. Compute the allowlist from parent before inflateFromResource(themedCtx, desc.accountPreferencesId, parent) and call filterBlockedFragments directly after it. The material shows no commit for 12, 12L or 13, which are listed as affected. The same hunk should apply if AccountTypePreferenceLoader has the same inflation site there." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 5, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "8261e0ade3b414fea61d7fe9d8bc6df7a3fc8603", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40658", "osv_id": "ASB-A-329641908", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "Adds a size consistency check in SoftVideoDecoderOMXComponent::getConfig for kDescribeHdr10PlusInfoIndex. It rejects a client-supplied nParamSize larger than the trailing storage described by nSize, before the HDR10+ info is memcpy'd into outParams->nValue.", "confidence": "high", "backport_notes": [ "Single self-contained hunk in SoftVideoDecoderOMXComponent::getConfig, right after the isValidOMXParam(outParams) check in the kDescribeHdr10PlusInfoIndex case. The bulletin also lists 12, 12L and 13 as affected, but the material does not show the code on those branches. Check that the case exists and matches there before applying." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/frameworks/av", "sha": "6d23fa05a40e5462d4b9bad28afa932e6e12a4f3", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/frameworks/av" ] }, { "cve": "CVE-2024-40659", "osv_id": "ASB-A-336976105", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "DoS" ], "status": "resolved", "brief": { "summary": "Restricts the exported rkpdapp RemoteProvisioningService so that only system_server (SYSTEM_UID) or rkpdapp itself can use the getRegistration API. It does this by adding a BIND_RKP_SERVICE permission to the service in the manifest and a calling-UID check in the binder implementation.", "confidence": "high", "backport_notes": [ "The fix spans two repositories. In frameworks/base, core/res/AndroidManifest.xml gets the permission definition (BIND_RKP_SERVICE, signature). In RemoteKeyProvisioning, rkpdapp gets the manifest attribute and the UID check. Apply the frameworks/base definition first or together with the rkpdapp change. The in-code UID check in getRegistration enforces the restriction regardless of the manifest attribute. SYSTEM_UID callers pass component permission checks regardless of grants (general platform knowledge).", "The commit is marked 'Flag: EXEMPT Mainline module change' (RemoteKeyProvisioning module)." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 4, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/packages/modules/RemoteKeyProvisioning", "sha": "c65dce4c6d8d54e47dce79a56e29e2223a2354e6", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/modules/RemoteKeyProvisioning" ] }, { "cve": "CVE-2024-40662", "osv_id": "ASB-A-261721900", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "brief": { "summary": "Uri.Builder.scheme(String) in android.net.Uri now removes every \"://\" sequence from a non-null scheme before storing it, so a caller-supplied scheme can no longer carry that scheme delimiter into the built Uri.", "confidence": "medium", "backport_notes": [ "This is a self-contained change to one method, Uri.Builder.scheme(), with no dependencies shown. Use the replace() form, as in the 14 backport and the 15 follow-up. The test needs android.platform.test.annotations.AsbSecurityTest to be available in FrameworksCoreTests (general platform knowledge).", "android.net.Uri lives in frameworks/base core rather than a mainline module, so the fix ships with the platform image (general platform knowledge)." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 9, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "method": [ "bug_id" ], "confidence": "certain", "first_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "last_fix": { "tag": "android-security-14.0.0_r12", "date": "2024-09-03", "provenance": "security_tag" }, "public_commits": [ { "project": "platform/frameworks/base", "sha": "e7af00cafb52a25933ec4edb80c5111d42af0237", "tag": "android-security-14.0.0_r12", "provenance": "security_tag", "method": "bug_id", "confidence": "certain", "evidence": null, "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/frameworks/base" ] } ], "tags": [ "android-security-14.0.0_r12" ], "unannounced": [], "coverage": { "n_ingested_tags": 30, "first_ingested_tag": "android-security-14.0.0_r1", "latest_ingested_tag": "android-security-14.0.0_r30", "window_base_tag": "android-14.0.0_r1", "window_start": "2023-10-04", "partial_tags": [] }, "platform_update_tags": {}, "briefs": { "CVE-2024-32896": { "cve": "CVE-2024-32896", "summary": "RecoverySystemService.rebootRecoveryWithCommand() now destroys all KeyMint keys via the new AndroidKeyStoreMaintenance.deleteAllKeys() (IKeystoreMaintenance.deleteAllKeys) before rebooting to recovery when the command contains \"--wipe_data\", with a matching SELinux allow for system_server, so FBE-encrypted data becomes unrecoverable even if the recovery data wipe is interrupted or skipped.", "component": "platform/frameworks/base, RecoverySystemService / android.security.AndroidKeyStoreMaintenance; platform/system/sepolicy, system_server keystore2 policy", "weakness": "Incomplete cleanup / insufficient data destruction: keys protecting FBE encryption material were not destroyed before the wipe was deferred to recovery", "root_cause": "Before the fix, a factory reset request through RecoverySystemService.rebootRecoveryWithCommand() only wrote the command (including \"--wipe_data\") into the BCB via setupOrClearBcb(true, command) and then called PowerManager.reboot(REBOOT_RECOVERY), leaving data destruction to recovery after the reboot. The Keystore/KeyMint keys that protect the synthetic password blobs (used by LockSettingsService to derive FBE keys) and the keys protecting DE and metadata encryption keys (used by vold) stayed intact until recovery ran. Per the commit messages, if the recovery wipe was interrupted or skipped, the FBE-encrypted data could still be recovered.", "fix_analysis": [ "platform/system/sepolicy private/system_server.te and prebuilts/api/34.0/private/system_server.te: adds delete_all_keys to the existing 'allow system_server keystore:keystore2 { ... }' rule so system_server may invoke IKeystoreMaintenance.deleteAllKeys().", "keystore/java/android/security/AndroidKeyStoreMaintenance.java: new static deleteAllKeys() that calls StrictMode.noteDiskWrite(), then getService().deleteAllKeys() on the android.security.maintenance IKeystoreMaintenance binder. RemoteException and NullPointerException are converted to KeyStoreException(SYSTEM_ERROR); ServiceSpecificException is converted to KeyStoreException(e.errorCode).", "services/core/java/com/android/server/recoverysystem/RecoverySystemService.java rebootRecoveryWithCommand(): adds constant RECOVERY_WIPE_DATA_COMMAND = \"--wipe_data\" and computes isForcedWipe = command != null && command.contains(RECOVERY_WIPE_DATA_COMMAND). Inside the sRequestLock block, after setupOrClearBcb(true, command) succeeds and before pm.reboot(PowerManager.REBOOT_RECOVERY), it calls deleteSecrets() when isForcedWipe is true.", "RecoverySystemService.deleteSecrets(): logs Slogf.w(TAG, \"deleteSecrets\"), calls AndroidKeyStoreMaintenance.deleteAllKeys(), and on android.security.KeyStoreException logs Log.wtf and returns; the reboot still proceeds." ], "completeness": [ "Key destruction runs only when the command string contains \"--wipe_data\"; recovery commands without that substring do not trigger deleteSecrets().", "Only the RecoverySystemService.rebootRecoveryWithCommand() path is covered; the material shows no other path that writes a wipe command to the BCB.", "Failure of deleteAllKeys() is only logged with Log.wtf; the device still reboots to recovery with the wipe deferred, so in that failure case the pre-fix behavior remains.", "deleteSecrets() runs only if setupOrClearBcb(true, command) succeeded; if BCB setup fails the method returns early without rebooting.", "The sepolicy change grants system_server the delete_all_keys permission the Java call relies on; any failure of the call is logged and not retried." ], "behavior_changes": [ "Factory reset via rebootRecoveryWithCommand with \"--wipe_data\" now deletes all keys in all KeyMint devices (including synthetic password protector keys and vold DE/metadata protector keys) before the reboot, intended to make FBE-encrypted data unrecoverable even if recovery does not complete the wipe.", "New warning log \"deleteSecrets\" from RecoverySystemService, and Log.wtf \"Failed to delete all keys from keystore.\" on failure.", "system_server gains the keystore2 delete_all_keys permission in SELinux policy.", "Per the commit test notes, if the wipe is interrupted after the fix, the device reboots into recovery and prompts for a factory reset ('Cannot load Android system. Your data may be corrupt. ...')." ], "preconditions": [ "A factory reset / data wipe is initiated through RecoverySystemService.rebootRecoveryWithCommand(), reached from RecoverySystem.bootCommand() in frameworks/base/core/java/android/os/RecoverySystem.java (per index search); the service tests stub enforceCallingOrSelfPermission(RECOVERY) for this call (per index search).", "The recovery data wipe is interrupted or skipped, so the keystore keys protecting FBE material are not destroyed (per commit message); the bulletin rates this High EoP." ], "per_major": { "14": "same fix: frameworks/base 8b7b2c66ca96 and sepolicy 92cbf8d4f18c in android-security-14.0.0_r12 (Merged-In I5eb8e97f..., I5be2f9e8...); at android-security-14.0.0_r29 8/8 lines of the patched region present.", "15": "resolved at base (android-15.0.0_r1) per per-major facts; 6/6 lines of the patched region present at android-security-15.0.0_r17. The commit listed for 15, platform/build/soong 7ee98928ea1b ('Add secretkeeper-v1-java to platform APIs'), does not contain the deleteSecrets/deleteAllKeys logic.", "16": "not affected (not listed by the bulletin); 8/8 lines of the patched region present at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin); 8/8 lines of the patched region present at android-security-17.0.0_r1." }, "backport_notes": [ "Apply the sepolicy change (delete_all_keys in allow system_server keystore:keystore2, in both private/system_server.te and the matching prebuilts/api//private/system_server.te) together with the frameworks/base change; otherwise the deleteAllKeys() call can be expected to fail and would only be logged via Log.wtf. The Java side depends on IKeystoreMaintenance.deleteAllKeys() in the android.security.maintenance AIDL and on com.android.server.utils.Slogf.", "The Android 15 entry points to a soong change whose content does not match this fix. To verify, look directly for RECOVERY_WIPE_DATA_COMMAND / deleteSecrets() in RecoverySystemService and deleteAllKeys() in AndroidKeyStoreMaintenance." ], "confidence": "high", "unknowns": [ "Whether other paths exist that write a wipe command to the BCB or enter recovery without going through rebootRecoveryWithCommand (none shown in the material).", "Where the RECOVERY permission check for rebootRecoveryWithCommand is enforced (the diff does not show it; tests imply enforceCallingOrSelfPermission(RECOVERY)).", "How a missing sepolicy permission surfaces to the Java caller (error code not shown).", "The exact frameworks/base and sepolicy commits that carry this change on Android 15, since the listed 15 commit is a soong change with different content.", "Whether IKeystoreMaintenance.deleteAllKeys() was already present in the keystore2 AIDL and daemon on the 14 branch or was added by a separate, unlisted change." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 5, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40650": { "cve": "CVE-2024-40650", "summary": "Adds android:maxLength=500 to the wifi_item_edit_content style in Settings res/values/styles.xml, so edit fields using that style (the commit tests it on \"Add network\") accept at most 500 characters.", "component": "platform/packages/apps/Settings, Wi-Fi network configuration UI resources (res/values/styles.xml, style wifi_item_edit_content)", "weakness": "Missing input length bound (improper input validation) on user-editable text fields", "root_cause": "The wifi_item_edit_content style declared padding, layout margin, text alignment, text appearance, hint color and minHeight, but no android:maxLength. Edit fields using this style therefore had no length limit at the UI layer. The style name and the commit's test note (\"Add network\") tie it to the Wi-Fi network configuration UI. The bulletin rates the issue High / EoP. The material does not show the code that consumes the field values or how an oversized value leads to the issue.", "fix_analysis": [ "res/values/styles.xml, style wifi_item_edit_content: adds 500. Every text view using this style now has its content capped at 500 characters (android:maxLength installs an InputFilter.LengthFilter on the TextView (general platform knowledge)).", "This is a single one-line resource change. The commit adds no Java logic and no new validation." ], "completeness": [ "Covers only views that use the wifi_item_edit_content style. Edit fields that use a different style or set their attributes inline are not touched by this diff.", "The neighbouring styles wifi_item_content, wifi_item_spinner and wifi_advanced_toggle in the same file are unchanged. The material does not show which views use them.", "The fix is a UI-layer length cap. It adds no length validation in the code that consumes the field values. The material does not show whether other entry points to that code exist." ], "behavior_changes": [ "Users can no longer enter more than 500 characters into any field styled with wifi_item_edit_content. Extra input is dropped by the length filter (general platform knowledge)." ], "preconditions": [ "Access to the Settings Wi-Fi network configuration UI (the commit's test note cites \"Add network\").", "Entering a string longer than 500 characters into a field that uses the wifi_item_edit_content style." ], "per_major": { "14": "same fix: 2968ccc91195 (a cherry-pick of 855053ca4124) landed in android-security-14.0.0_r12. At android-security-14.0.0_r29, 4/4 lines of the patched region are present (the maxLength item is at styles.xml line 124).", "15": "same fix: commit 092668676af7 is in the android-15.0.0_r1 base. At android-security-15.0.0_r17, 4/4 lines of the patched region are present.", "16": "not affected (not listed by the bulletin). The patched region is present at android-security-16.0.0_r8 (4/4 lines).", "17": "not affected (not listed by the bulletin). At android-security-17.0.0_r1, 3/4 lines of the patched region are present. The material does not show which line differs." }, "backport_notes": [ "Pure resource change: add 500 inside the wifi_item_edit_content style in res/values/styles.xml. On forks where the Wi-Fi edit fields use a different or renamed style, apply the attribute to the style or layout those fields actually use." ], "confidence": "medium", "unknowns": [ "Which layouts or EditTexts reference wifi_item_edit_content, and which code consumed the oversized value. The material shows only the style definition.", "Why the bulletin classifies the issue as EoP. The diff alone does not show the mechanism.", "Whether and how the fix was applied to Android 12, 12L and 13, which the bulletin lists as affected. No per-major facts are given for them.", "Which of the 4 patched-region lines differs on Android 17 (android-security-17.0.0_r1), and why." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 7, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40652": { "cve": "CVE-2024-40652", "summary": "SettingsHomepageActivity.onCreate now reads Settings.Global.DEVICE_PROVISIONED and immediately finishes the activity when the device is not yet provisioned, so the Settings homepage cannot be used before setup completes.", "component": "platform/packages/apps/Settings, homepage (SettingsHomepageActivity)", "weakness": "Missing state/authorization check: the Settings home activity could be launched before device provisioning (setup wizard) was completed.", "root_cause": "SettingsHomepageActivity.onCreate performed no check of the device provisioning state. Any launch of the activity (the commit message cites launching via ADB during Setup, or tapping the Settings launcher icon after bypassing Setup) proceeded to build the full Settings homepage regardless of whether DEVICE_PROVISIONED was set, exposing Settings functionality during the setup phase.", "fix_analysis": [ "src/com/android/settings/homepage/SettingsHomepageActivity.java:onCreate: right after super.onCreate(), read android.provider.Settings.Global.DEVICE_PROVISIONED via getContentResolver() with default 0 (so a missing value is treated as unprovisioned).", "If the value is 0, log 'Device is not provisioned, exiting Settings' at error level, call finish(), and (in the Android 14 cherry-pick 2909433f7d59) return before any of the remaining onCreate logic (embedding/managed-profile forwarding, view setup) runs.", "The Android 15 base commit 70a5a0fd353c adds the same check but without the 'return;' after finish(), and adds a Robolectric test launch_deviceUnprovisioned_finish in tests/robotests/.../SettingsHomepageActivityTest.java plus a @Before that sets DEVICE_PROVISIONED=1 for the other tests.", "The code comment marks this as an interim measure (TODO b/331254029) to be replaced by an allowlist." ], "completeness": [ "Covers SettingsHomepageActivity and its subclasses (context shows DeepLinkHomepageActivity is an instance of it), since the check is in the shared onCreate.", "The check is only in this one activity; other Settings entry points are not touched by this diff, so whether they are reachable before provisioning is not addressed here. The TODO in the code acknowledges the gate is interim pending an allowlist.", "The check is performed once in onCreate; it reads the global setting with default 0, so it fails closed when the setting is absent.", "In the Android 15 base diff there is no 'return;' after finish(), so the rest of onCreate still executes for an unprovisioned device (the activity is marked finishing but initialization continues). The Android 14 cherry-pick includes the 'return;'." ], "behavior_changes": [ "Launching the Settings homepage while DEVICE_PROVISIONED is 0 (or unset) now closes the activity immediately and logs 'Device is not provisioned, exiting Settings' at Log.e.", "Robolectric tests for SettingsHomepageActivity now require DEVICE_PROVISIONED=1 to be set in @Before (Android 15 test change)." ], "preconditions": [ "Device in an unprovisioned state (Settings.Global.DEVICE_PROVISIONED == 0 or unset), i.e. before Setup Wizard completion.", "Ability to start SettingsHomepageActivity (the commit message tests use ADB launch during Setup, or the launcher Settings icon after bypassing Setup)." ], "per_major": { "14": "same fix: RESTRICT AUTOMERGE cherry-pick 2909433f7d59 in android-security-14.0.0_r12, with finish() followed by return; 5/5 lines present at android-security-14.0.0_r29.", "15": "base fix 70a5a0fd353c in android-15.0.0_r1; the shown diff lacks the 'return;' after finish() and adds a Robolectric test; 8/8 lines of the patched region present at android-security-15.0.0_r17.", "16": "not affected (not listed by the bulletin); the patched region is present (5/5 lines) at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin); the patched region is present (5/5 lines) at android-security-17.0.0_r1." }, "backport_notes": [ "Single-file, self-contained change with no new dependencies; prefer the Android 14 form (finish() followed by return) so no further onCreate initialization runs on an unprovisioned device." ], "confidence": "high", "unknowns": [ "What specific Settings functionality was reachable pre-provisioning and what privilege was gained; the material only shows the gate being added.", "Whether a later Android 15 commit (e.g. the other cherry-pick c02f4ee1936e referenced in the commit message) added the 'return;' that the base diff omits.", "Whether other Settings activities received similar provisioning gates in separate commits." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 2, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40654": { "cve": "CVE-2024-40654", "summary": "SearchResultTrampoline now identifies its launcher with getLaunchedFromPackage() instead of getCallingActivity(), and SearchFeatureProvider.verifyLaunchSearchResultPageCaller now takes the launching package name instead of the result-receiving ComponentName.", "component": "platform/packages/apps/Settings, search (SearchResultTrampoline / SearchFeatureProviderImpl)", "weakness": "Authorization check based on the wrong caller identity source (getCallingActivity() reports who will receive the result, not who launched the activity)", "root_cause": "SearchResultTrampoline.onCreate took the identity of whoever launched the trampoline from getCallingActivity(). It passed that value to SearchFeatureProviderImpl.verifyLaunchSearchResultPageCaller, which allowed the launch if the package was Settings, the SettingsIntelligence package, or signature-allowlisted. The same ComponentName also drove the isSettingsIntelligence() branch, which selects how the result page is launched (including DeepLinkHomepageActivityInternal). The commit message says getCallingActivity() reports who will get the Activity result, not who launched the activity or built the PendingIntent used to launch it. The privilege check was therefore keyed on a value that does not identify the launching package.", "fix_analysis": [ "src/com/android/settings/search/SearchResultTrampoline.java:onCreate: replaces getCallingActivity() with getLaunchedFromPackage(), which returns a String, and passes it to verifyLaunchSearchResultPageCaller. The same value is then used for the isSettingsIntelligence() branch.", "src/com/android/settings/search/SearchResultTrampoline.java:isSettingsIntelligence: the parameter changes from ComponentName to String. The method is now a plain TextUtils.equals against getSettingsIntelligencePkgName(this), and the explicit null check is dropped. TextUtils.equals handles null (general platform knowledge).", "src/com/android/settings/search/SearchFeatureProvider.java: the interface method changes to verifyLaunchSearchResultPageCaller(@NonNull Context, @NonNull String callerPackage).", "src/com/android/settings/search/SearchFeatureProviderImpl.java:verifyLaunchSearchResultPageCaller: the null check becomes TextUtils.isEmpty(callerPackage), which throws IllegalArgumentException. The isSettingsPackage comparison and isSignatureAllowlisted now use callerPackage directly. The decision logic is otherwise unchanged. The unused TAG and the ComponentName import are removed.", "tests/robotests/.../SearchFeatureProviderImplTest.java: the three existing tests now pass package name strings instead of ComponentName." ], "completeness": [ "Covers both uses of the caller identity in SearchResultTrampoline: the privilege check and the isSettingsIntelligence() launch-mode branch. Both now use the launching package.", "The allowlist logic itself (isSignatureAllowlisted, and the Settings and SettingsIntelligence package comparisons) is unchanged. Only the identity passed into it changes.", "The IllegalArgumentException message still says the intents 'must be called with startActivityForResult', which no longer matches the new identity source. This is cosmetic.", "The material shows no other callers of verifyLaunchSearchResultPageCaller. Custom SearchFeatureProvider implementations are outside the material." ], "behavior_changes": [ "The caller identity is now the package reported by getLaunchedFromPackage() (the launcher, or whoever built the PendingIntent), not the package of the result-receiving activity.", "An empty or null caller package now throws IllegalArgumentException (TextUtils.isEmpty check).", "SearchFeatureProvider interface signature change: every implementation of verifyLaunchSearchResultPageCaller must switch to the String parameter." ], "preconditions": [ "An intent that starts com.android.settings.search.SearchResultTrampoline. The 'ExternalSettingsTrampoline' error text suggests external launches; the material does not show whether the activity is exported.", "Before the fix, the check passed only if the package of the ComponentName returned by getCallingActivity() was Settings, the SettingsIntelligence package, or signature-allowlisted." ], "per_major": { "14": "same fix: f1d0079c9173 (Change-Id If97018c2741caef622f0596bbfeaa42ef1788b78, cherry-picked from 901880a1d2e6) in android-security-14.0.0_r8. 7/8 lines of the patched region are still present at android-security-14.0.0_r29.", "15": "fix present in base android-15.0.0_r1 through merge commit a339d8ea9a16 ([RESTRICT AUTOMERGE] merge from sc-v2-dev); its combined diff in SearchResultTrampoline contains isSettingsIntelligence(callerPackage). Only 2/8 lines of the patched region match at android-security-15.0.0_r17, and the material does not explain why.", "16": "not affected (not listed by the bulletin); 7/8 lines of the patched region present at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin); 7/8 lines of the patched region present at android-security-17.0.0_r1." }, "backport_notes": [ "Single commit, but it changes the SearchFeatureProvider interface. Update every implementation (including any OEM FeatureFactory override) and the robotests together, or the build breaks.", "The SearchResultTrampoline hunk touches the activity-embedding / isSettingsIntelligence branch, and that code differs between branches (see the Android 15 merge diff), so check that hunk by hand." ], "confidence": "high", "unknowns": [ "Whether SearchResultTrampoline is exported and which intent filters or actions reach it (the manifest is not in the material).", "The concrete scenario in which getCallingActivity() reported an allowed package for a non-allowed launcher (no details of bug 316891059 are provided).", "What getLaunchedFromPackage() returns for each launch mode (plain startActivity, startActivityForResult, PendingIntent), and so which exception each launch path now gets.", "The contents of isSignatureAllowlisted and of the allowlist itself.", "Why only 2/8 lines of the patched region match on Android 15." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40655": { "cve": "CVE-2024-40655", "summary": "Adds an unbindService() call to the call-screening timeout handler in Telecom's CallScreeningServiceHelper so that a CallScreeningService that never responds is released after the timeout instead of staying bound.", "component": "platform/packages/services/Telecomm, outgoing call screening (CallScreeningServiceHelper)", "weakness": "Missing resource release (service connection never unbound on the timeout path), allowing a role-holding app to keep its service alive via a persistent system-initiated binding", "root_cause": "CallScreeningServiceHelper.bindAndGetCallIdentification() binds to the ROLE_CALL_SCREENING holder's service and posts a timeout runnable (Timeouts.getCallScreeningTimeoutMillis). Before the fix, the timeout runnable only completed mFuture with null and ended the log session. It never called unbindService(serviceConnection). Per the commit message, the code assumed the service would use MSG_SCREEN_CALL to screen the call and that the connection would be unbound for outgoing calls once screening completed. A plain service holding ROLE_CALL_SCREENING that does not complete screening therefore stayed bound by Telecom after the timeout, which kept the service alive. The onNullBinding path already unbound (line 156 in context). The timeout path did not.", "fix_analysis": [ "src/com/android/server/telecom/CallScreeningServiceHelper.java:bindAndGetCallIdentification (timeout runnable posted via handler.postDelayed): after mFuture.complete(null), adds mContext.unbindService(serviceConnection) so the binding is torn down when the timeout fires.", "Same runnable: adds a catch (IllegalArgumentException e) that logs via Log.i(this, \"Exception when unbinding service %s : %s\", ...). This absorbs the exception that Context.unbindService throws when the connection is not currently bound (for example, already unbound by another path, or the original bind failed). The finally { Log.endSession(); } block is unchanged.", "Single-commit fix. Android 14 received it as a cherry-pick (Change-Id I30d276867c571ece113106d3b363fce99d64f441, cherry-picked from 9d97cd5825066ac8e15bbf97f6755663c5341afb)." ], "completeness": [ "Covers the timeout path of the outgoing-call screening binding in CallScreeningServiceHelper. Together with the existing unbind in onNullBinding, the connection is now released on null binding and on timeout. The normal response path is not visible in the material.", "The unbind in the timeout runnable is unconditional: it runs even if mFuture already completed. It relies on the new IllegalArgumentException catch for the already-unbound case.", "Only the CallScreeningServiceHelper (outgoing call identification) binding is touched. The material does not show whether other Telecom code paths that bind a CallScreeningService (for example, incoming-call screening) have their own timeout/unbind handling.", "The timeout duration itself (Timeouts.getCallScreeningTimeoutMillis) is unchanged. The service can still stay bound for up to that timeout per outgoing call." ], "behavior_changes": [ "When the call-screening timeout fires, Telecom now calls unbindService on the CallScreeningService connection. Per the commit's manual test, the service's onDestroy is called after the timeout.", "A new Log.i line is emitted if unbindService throws IllegalArgumentException.", "No change to the timeout value or the future result: mFuture is still completed with null on timeout." ], "preconditions": [ "An app holds ROLE_CALL_SCREENING and implements a service that does not complete screening.", "An outgoing call is placed so that Telecom invokes CallScreeningServiceHelper.bindAndGetCallIdentification and binds to that service. Per index search, callers such as Dialer's TelecomUtil.placeCall use TelecomManager.placeCall. The path from there to this helper is not shown in the material.", "The bind succeeds (bindCallScreeningService returns true) and the screening timeout elapses without the service completing screening." ], "per_major": { "14": "same fix: cherry-pick eeef54b37a36 of the same 4-line change in android-security-14.0.0_r12 (linked by bug 300904123). All 3 patched lines are present at android-security-14.0.0_r29.", "15": "same fix: original commit 9d97cd582506 is in the base release android-15.0.0_r1. The patched region is present at android-security-15.0.0_r17.", "16": "not affected (not listed by the bulletin). The patched region is present at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin). The patched region is present at android-security-17.0.0_r1." }, "backport_notes": [ "The change is self-contained. Insert mContext.unbindService(serviceConnection) after mFuture.complete(null) in the postDelayed timeout lambda of CallScreeningServiceHelper.bindAndGetCallIdentification, and add a catch for IllegalArgumentException before the existing finally { Log.endSession(); }. The Log.i(Object, String, Object...) form is used. On older trees, verify that this overload exists or use the Log.w(TAG, ...) form already present in the same block." ], "confidence": "high", "unknowns": [ "The material does not show the onServiceConnected path of this ServiceConnection, so how the connection is unbound on the normal (service responds) path is not visible.", "The material does not show whether other CallScreeningService binding sites in Telecom (incoming call screening) share the same missing-unbind pattern.", "The material does not show how outgoing calls from TelecomManager.placeCall reach CallScreeningServiceHelper.", "The material does not detail the concrete impact of the kept-alive service beyond keeping the service alive (the bulletin rates it High EoP)." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 4, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40656": { "cve": "CVE-2024-40656", "summary": "Adds a cross-user validation of the StatusHints icon carried by a ParcelableConference in ConnectionServiceWrapper's handleCreateConferenceComplete callback. It uses the Binder calling user, captured before the calling identity is cleared.", "component": "platform/packages/services/Telecomm, ConnectionServiceWrapper (ConnectionService adapter callbacks)", "weakness": "Missing user-boundary validation of a caller-supplied Icon (cross-user information disclosure)", "root_cause": "In src/com/android/server/telecom/ConnectionServiceWrapper.java, handleCreateConferenceComplete(String callId, ConnectionRequest request, ParcelableConference conference, Session.Info sessionInfo) accepted the ParcelableConference from the ConnectionService, cleared the Binder calling identity and forwarded the conference without checking that the Icon in its StatusHints belonged to the calling user. Per the commit message, a conference call could therefore display an image from another user.", "fix_analysis": [ "src/com/android/server/telecom/ConnectionServiceWrapper.java, handleCreateConferenceComplete (in the ConnectionService adapter inside ConnectionServiceWrapper): the fix captures `UserHandle callingUserHandle = Binder.getCallingUserHandle()` before `Binder.clearCallingIdentity()`. This records the caller's user even though the rest of the method runs with cleared identity.", "Same method, inside `synchronized (mLock)`: if `conference.getStatusHints() != null`, the fix reads the Icon and replaces it with `StatusHints.validateAccountIconUserBoundary(icon, callingUserHandle)` via `setIcon(...)`. This matches the check visible in handleCreateConnectionComplete at android-security-14.0.0_r29.", "The fix is a single commit: 7 inserted lines in one file." ], "completeness": [ "Covers the conference creation completion path (handleCreateConferenceComplete), and only for the StatusHints icon. At r29, the connection creation path (handleCreateConnectionComplete) has the same check. The material does not show when that check was added.", "Only the icon inside StatusHints is validated. The change touches no other fields of ParcelableConference.", "The material does not show whether other ConnectionService-to-Telecom paths that can deliver StatusHints do the same validation.", "The material does not include how StatusHints.validateAccountIconUserBoundary behaves." ], "behavior_changes": [ "Status hint icons in a ParcelableConference delivered by a ConnectionService now pass through StatusHints.validateAccountIconUserBoundary against the calling user. An icon that fails the check is replaced by whatever that helper returns (its body is not shown).", "Binder.getCallingUserHandle() is now read at the start of the callback. The diff adds no new error codes or exceptions." ], "preconditions": [ "A ConnectionService bound by Telecom returns a ParcelableConference via the handleCreateConferenceComplete callback.", "The ParcelableConference carries non-null StatusHints with an Icon." ], "per_major": { "14": "same fix: cherry-picked as f3e6a6c02439 into android-security-14.0.0_r12 (linked by bug 329058967). At android-security-14.0.0_r29, all 8 lines of the patched region are present. The check now sits after the mScheduledFutureMap lookup, which also has a `call != null` guard there.", "15": "same fix: present as 8c619f58c000 in the android-15.0.0_r1 base with an identical hunk. All 8 lines are present at android-security-15.0.0_r17.", "16": "not affected (not listed by the bulletin). The patched region is present (8/8 lines) at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin). The patched region is present (8/8 lines) at android-security-17.0.0_r1." }, "backport_notes": [ "The fix calls StatusHints.validateAccountIconUserBoundary(Icon, UserHandle), so confirm that this helper exists on the target branch. The 14 and 15 hunks are identical apart from line offsets." ], "confidence": "high", "unknowns": [ "The material does not include the implementation of StatusHints.validateAccountIconUserBoundary or what it returns for a rejected icon.", "The material does not show whether other paths that deliver StatusHints from a ConnectionService to Telecom carry the same validation.", "The material does not show when the matching check in handleCreateConnectionComplete was introduced.", "The material does not show how the unvalidated icon was loaded or rendered downstream." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40657": { "cve": "CVE-2024-40657", "summary": "Settings' AccountTypePreferenceLoader now neutralizes clicks on any preference inflated from an external account authenticator's accountPreferences XML whose android:fragment is not already present in the host preference group, so that external apps cannot have Settings open its internal fragments.", "component": "platform/packages/apps/Settings, accounts (AccountTypePreferenceLoader)", "weakness": "Missing validation of externally supplied preference metadata (an untrusted android:fragment attribute honored inside Settings)", "root_cause": "AccountTypePreferenceLoader takes the preference XML that an account authenticator references through desc.accountPreferencesId (a resource owned by the external authenticator package) and inflates it into a Settings PreferenceFragmentCompat with mFragment.getPreferenceManager().inflateFromResource(themedCtx, desc.accountPreferencesId, parent). Before this fix, nothing checked the android:fragment attribute of the inflated preferences. A preference supplied by the external app could therefore name a fragment class that would open inside Settings when tapped, giving external applications access to internal Settings fragments (per the commit comment).", "fix_analysis": [ "src/com/android/settings/accounts/AccountTypePreferenceLoader.java, in the method that loads desc.accountPreferencesId: before inflation, it calls the new generateFragmentAllowlist(parent). This collects every non-empty Preference.getFragment() value already present in the host group, recursing through nested PreferenceGroups.", "Same method: directly after inflateFromResource(...), it calls the new filterBlockedFragments(prefs, fragmentAllowList). This recursively walks the inflated group. For every Preference whose getFragment() is non-null and not in the allowlist, it installs an OnPreferenceClickListener that returns true, consuming the click so the named fragment is not launched.", "generateFragmentAllowlist and filterBlockedFragments are package-visible (@VisibleForTesting) and null-safe: a null group returns an empty set or does nothing. The Android 15 commit also adds Robolectric tests in tests/robotests/src/com/android/settings/accounts/AccountTypePreferenceLoaderTest.java. The Android 14 security cherry-pick changes only the source file." ], "completeness": [ "Covers the inflation site in AccountTypePreferenceLoader where an external authenticator's preference XML is inflated, including nested PreferenceGroups.", "The fragment attribute is not cleared; the fix only overrides the click listener. Any later code that replaces the OnPreferenceClickListener on the same preference could undo the block. The material does not show whether such code exists.", "The allowlist is made of the fragments already in the host group before inflation. An external XML that names one of those same fragment classes is still allowed.", "Only android:fragment is addressed. Intent handling in the class is not changed by this commit." ], "behavior_changes": [ "Preferences from an authenticator's accountPreferences XML that declare an android:fragment not already in the host screen now do nothing when clicked, instead of opening a fragment. The fix adds no log message.", "Authenticator apps that used android:fragment in their account preferences lose that behavior. The commit comment says these preferences are rendered into Settings and cannot reach their own Fragments, so there is no acceptable usage of android:fragment here." ], "preconditions": [ "An installed app registers an account authenticator whose description has a non-zero accountPreferencesId pointing to a preference XML that contains android:fragment attributes.", "The user opens the Settings page for that account type, so AccountTypePreferenceLoader inflates the external resource, and then taps the preference.", "Settings runs with the system shared UID (general platform knowledge)." ], "per_major": { "14": "same fix: commit 8261e0ade3b4, cherry-picked into android-security-14.0.0_r12 (source only, no test file). The patched region is fully present at android-security-14.0.0_r29.", "15": "same fix: commit 2cb9b10ed97b in android-15.0.0_r1 (same source change plus Robolectric tests). The patched region is fully present at android-security-15.0.0_r17.", "16": "not affected (not listed by the bulletin). The patched region is present at android-security-16.0.0_r8.", "17": "not affected (not listed by the bulletin). The patched region is present at android-security-17.0.0_r1." }, "backport_notes": [ "This is a single self-contained commit that adds androidx.annotation, androidx.collection.ArraySet and java.util.Set imports. Compute the allowlist from parent before inflateFromResource(themedCtx, desc.accountPreferencesId, parent) and call filterBlockedFragments directly after it. The material shows no commit for 12, 12L or 13, which are listed as affected. The same hunk should apply if AccountTypePreferenceLoader has the same inflation site there." ], "confidence": "high", "unknowns": [ "The material does not show fix commits for Android 12, 12L and 13, which the bulletin lists as affected.", "The body of updatePreferenceIntents and its call order relative to filterBlockedFragments are not shown, so it is unknown whether a later listener assignment could override the blocking listener.", "The material does not describe which internal Settings fragment(s) were reachable in the original report." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 5, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40658": { "cve": "CVE-2024-40658", "summary": "Adds a size consistency check in SoftVideoDecoderOMXComponent::getConfig for kDescribeHdr10PlusInfoIndex. It rejects a client-supplied nParamSize larger than the trailing storage described by nSize, before the HDR10+ info is memcpy'd into outParams->nValue.", "component": "platform/frameworks/av, libstagefright OMX software video decoder (media/libstagefright/omx/SoftVideoDecoderOMXComponent.cpp)", "weakness": "Missing bounds check leading to an out-of-bounds write on memcpy", "root_cause": "In SoftVideoDecoderOMXComponent::getConfig, case kDescribeHdr10PlusInfoIndex, the only check on the client-supplied DescribeHDR10PlusInfoParams was isValidOMXParam(outParams). The code then treated the client-controlled outParams->nParamSize as the capacity of the trailing nValue array: if nParamSize >= info->size(), it ran memcpy(outParams->nValue, info->data(), info->size()). Nothing checked that offsetof(DescribeHDR10PlusInfoParams, nValue) + nParamSize fits within the declared structure size nSize. A caller could therefore claim an nParamSize larger than the space described by nSize, and the memcpy could write past the declared end of the params structure.", "fix_analysis": [ "media/libstagefright/omx/SoftVideoDecoderOMXComponent.cpp:SoftVideoDecoderOMXComponent::getConfig (case kDescribeHdr10PlusInfoIndex): right after isValidOMXParam(outParams), a new check returns OMX_ErrorBadParameter when offsetof(DescribeHDR10PlusInfoParams, nValue) + outParams->nParamSize > outParams->nSize. This ties the claimed payload capacity (nParamSize) to the declared total structure size (nSize), so the later memcpy, which only runs when 'outParams->nParamSize >= info->size()', can only write within the structure described by nSize.", "On rejection the fix logs ALOGE with the bug id and calls android_errorWriteLog(0x534e4554, \"329641908\"), then returns OMX_ErrorBadParameter.", "Single commit, 7 lines added, no other files touched." ], "completeness": [ "The fix covers the only memcpy into outParams->nValue in the kDescribeHdr10PlusInfoIndex branch of getConfig. The check runs before nParamSizeUsed is written and before the memcpy, so it gates both the copy and the erase of the pending entry.", "The check relies on nSize matching the real allocation. The material does not show whether isValidOMXParam or the caller enforces this.", "Only the getConfig (output) direction changes. The internalSetConfig path (it starts at line 648 in the shown context) and any HDR10+ input handling are not shown in the material, and this commit does not touch them.", "Other OMX components with their own getConfig (for example the Goldfish and Qualcomm vendor decoders, per index search) are separate code that this fix does not modify. The material does not show whether they implement an HDR10+ info query." ], "behavior_changes": [ "getConfig(kDescribeHdr10PlusInfoIndex) now returns OMX_ErrorBadParameter when offsetof(DescribeHDR10PlusInfoParams, nValue) + nParamSize > nSize, instead of continuing.", "On rejection the component now emits a new ALOGE line and an android_errorWriteLog(0x534e4554, \"329641908\") event.", "Well-formed clients whose nParamSize fits within the storage after nValue inside nSize see no change." ], "preconditions": [ "The caller can issue an OMX getConfig with index kDescribeHdr10PlusInfoIndex against a software decoder derived from SoftVideoDecoderOMXComponent.", "supportDescribeHdr10PlusInfo() returns true for the component.", "mHdr10PlusOutputs is non-empty, meaning pending HDR10+ info is waiting to be returned.", "The client supplies a DescribeHDR10PlusInfoParams that passes isValidOMXParam but has offsetof(nValue) + nParamSize > nSize, and nParamSize >= info->size(), so the memcpy branch runs." ], "per_major": { "14": "same fix: commit 6d23fa05a40e (a cherry-pick) in android-security-14.0.0_r12, linked by bug 329641908. At android-security-14.0.0_r29, 3/3 lines of the patched region are present.", "15": "same fix: commit 899a582bba88 (identical diff) is in the android-15.0.0_r1 base. At android-security-15.0.0_r17, 3/3 lines are present.", "16": "not affected (the bulletin does not list it). The patched region is present at android-security-16.0.0_r8 (3/3 lines).", "17": "not affected (the bulletin does not list it). The patched region is present at android-security-17.0.0_r1 (3/3 lines)." }, "backport_notes": [ "Single self-contained hunk in SoftVideoDecoderOMXComponent::getConfig, right after the isValidOMXParam(outParams) check in the kDescribeHdr10PlusInfoIndex case. The bulletin also lists 12, 12L and 13 as affected, but the material does not show the code on those branches. Check that the case exists and matches there before applying." ], "confidence": "high", "unknowns": [ "Whether internalSetConfig or any HDR10+ input-side path uses nParamSize without a similar check. The material does not show that code.", "The exact definition of DescribeHDR10PlusInfoParams and what isValidOMXParam enforces on nSize. Neither is included in the material.", "Whether nSize is guaranteed to match the real size of the params buffer supplied by the caller.", "Which process hosts the component on affected devices, and so the concrete privilege boundary. The bulletin only states High / EoP.", "How the fix looks on 12, 12L and 13." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 6, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40659": { "cve": "CVE-2024-40659", "summary": "Restricts the exported rkpdapp RemoteProvisioningService so that only system_server (SYSTEM_UID) or rkpdapp itself can use the getRegistration API. It does this by adding a BIND_RKP_SERVICE permission to the service in the manifest and a calling-UID check in the binder implementation.", "component": "platform/packages/modules/RemoteKeyProvisioning (rkpdapp, RemoteProvisioningService); companion permission definition in platform/frameworks/base core/res/AndroidManifest.xml (Android 15)", "weakness": "missing permission check / improper access control on an exported service", "root_cause": "In app/AndroidManifest.xml the service .service.RemoteProvisioningService was declared android:exported=\"true\" with an intent-filter for com.android.rkpdapp.IRemoteProvisioning and had no android:permission attribute. Its IRemoteProvisioning.Stub implementation in RemoteProvisioningService.java did not check who was calling. Any process could therefore bind to the service and reach the getRegistration path, which goes on to call ServiceManagerInterface.getInstance(irpcName). The new error message shows this API was meant only for system_server and rkpdapp itself. The bulletin classifies the impact as DoS (High).", "fix_analysis": [ "app/AndroidManifest.xml: the element gains android:permission=\"android.permission.BIND_RKP_SERVICE\" and stays exported, so a client must hold that permission to bind.", "app/src/com/android/rkpdapp/service/RemoteProvisioningService.java (IRemoteProvisioning.Stub implementation, getRegistration path per the commit title and the irpcName/IGetRegistrationCallback context): after the existing early-return validation, a new check compares Binder.getCallingUid() with Process.SYSTEM_UID and Process.myUid(). If the caller matches neither, the code calls callback.onError(\"Only system server and self are allowed to call RKP service.\") and returns before ServiceManagerInterface.getInstance(irpcName) runs. The imports android.os.Binder and android.os.Process are added.", "platform/frameworks/base core/res/AndroidManifest.xml (commit fb65afa14cdd, android-15.0.0_r1): defines the @hide permission android.permission.BIND_RKP_SERVICE with android:protectionLevel=\"signature\"." ], "completeness": [ "The fix adds two layers. The manifest permission gates binding to the service component. The UID check gates the getRegistration binder method itself, so even a caller that binds cannot get past that check unless it runs as SYSTEM_UID or rkpdapp's own UID.", "The diff places the UID check only on the getRegistration path. The material does not show whether IRemoteProvisioning has other methods, so coverage of other binder entry points cannot be judged.", "The new check comes after an existing early return whose content the diff does not show.", "The permission definition (BIND_RKP_SERVICE, signature) appears only in the Android 15 frameworks/base commit. The material does not show a matching definition on the Android 14 branch." ], "behavior_changes": [ "Binding to com.android.rkpdapp/.service.RemoteProvisioningService now requires android.permission.BIND_RKP_SERVICE.", "When a UID other than SYSTEM_UID or rkpdapp's own UID calls getRegistration, the call now ends with callback.onError(\"Only system server and self are allowed to call RKP service.\").", "On Android 15, the platform defines a new @hide signature-level permission, android.permission.BIND_RKP_SERVICE." ], "preconditions": [ "Before the fix: a process able to bind to the exported rkpdapp service through the com.android.rkpdapp.IRemoteProvisioning action could call getRegistration without any permission or UID check.", "After the fix: the caller must hold BIND_RKP_SERVICE and run as SYSTEM_UID or rkpdapp's UID.", "Per index search, native client code (system/security/provisioner/support/rkpd_client.cpp) reaches RKP through the \"remote_provisioning\" service name using IServiceManager." ], "per_major": { "14": "same fix: RemoteKeyProvisioning commit c65dce4c6d8d (RESTRICT AUTOMERGE, cherry-pick of internal d9c9db03) in android-security-14.0.0_r12. It adds the manifest permission attribute and the UID check. All 8/8 patched lines are present at android-security-14.0.0_r29. The material shows no frameworks/base permission definition for 14.", "15": "adapted fix: the BIND_RKP_SERVICE permission is defined in platform/frameworks/base commit fb65afa14cdd (core/res/AndroidManifest.xml, signature protectionLevel) in android-15.0.0_r1. 4/4 lines are present at android-security-15.0.0_r17. The material does not show the rkpdapp-side change for 15.", "16": "not affected per the bulletin; 8/8 lines of the patched region are present at android-security-16.0.0_r8.", "17": "not affected per the bulletin; 8/8 lines of the patched region are present at android-security-17.0.0_r1." }, "backport_notes": [ "The fix spans two repositories. In frameworks/base, core/res/AndroidManifest.xml gets the permission definition (BIND_RKP_SERVICE, signature). In RemoteKeyProvisioning, rkpdapp gets the manifest attribute and the UID check. Apply the frameworks/base definition first or together with the rkpdapp change. The in-code UID check in getRegistration enforces the restriction regardless of the manifest attribute. SYSTEM_UID callers pass component permission checks regardless of grants (general platform knowledge).", "The commit is marked 'Flag: EXEMPT Mainline module change' (RemoteKeyProvisioning module)." ], "confidence": "high", "unknowns": [ "Whether the BIND_RKP_SERVICE permission definition in frameworks/base was also applied to the Android 14 branch; the material only shows it for Android 15.", "Whether the rkpdapp manifest/UID-check change is present on Android 15; the material only shows the frameworks/base commit for 15.", "The exact method signature of getRegistration, any other methods of IRemoteProvisioning, and what the early-return validation before the new UID check does.", "The exact DoS mechanism the bulletin refers to; the material only shows the access-control gap." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 4, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } }, "CVE-2024-40662": { "cve": "CVE-2024-40662", "summary": "Uri.Builder.scheme(String) in android.net.Uri now removes every \"://\" sequence from a non-null scheme before storing it, so a caller-supplied scheme can no longer carry that scheme delimiter into the built Uri.", "component": "platform/frameworks/base, core/java/android/net/Uri.java (Uri.Builder)", "weakness": "Missing input validation on a URI component setter (scheme string accepted verbatim, allowing scheme delimiter injection)", "root_cause": "Uri.Builder.scheme(String scheme) assigned the argument directly to this.scheme with no validation. A scheme value containing \"://\" (for example \"http://https://evil.com:/te:st/\", the value used in the new test) was accepted and ended up in the built Uri's scheme and in its serialized \"://...\" form. That form then holds extra delimiters ahead of the real authority set with authority(). The material does not show how a consumer misuses this.", "fix_analysis": [ "core/java/android/net/Uri.java: Uri.Builder.scheme(String) now branches on null. A non-null scheme is stored as scheme.replace(\"://\", \"\"), which removes the occurrences of the three-character delimiter. A null scheme is still stored as null (relative Uri). The commit message says this narrow replacement was chosen over removing characters that are unsupported under IANA guidelines, because that could break apps that use custom schemes with asterisks.", "core/tests/coretests/src/android/net/UriTest.java: adds testSchemeSanitization (annotated @AsbSecurityTest(cveBugId = 261721900)). It builds a Uri with scheme \"http://https://evil.com:/te:st/\", authority \"google.com\" and path \"one/way\", then asserts that getScheme() is \"httphttpsevil.com:/te:st/\" and toString() is \"httphttpsevil.com:/te:st/://google.com/one/way\". The commit also adds the import android.platform.test.annotations.AsbSecurityTest.", "On Android 15, commit 003800764d61 (android-15.0.0_r1) changed an earlier scheme.replaceAll(\"://\", \"\") to scheme.replace(\"://\", \"\"). Its commit message says this optimized performance. The Android 14 backport e7af00cafb52 already uses the replace() form." ], "completeness": [ "Only the exact sequence \"://\" is removed from the scheme. The new test shows that ':' and '/' stay in the stored scheme (\"httphttpsevil.com:/te:st/\"), so the scheme is still not limited to standard scheme characters.", "The patched code makes a single replace() call and does not repeat it until no \"://\" is left. Removing one occurrence can join a leftover ':' with a following \"//\" and form a new \"://\" in the stored value. The material does not show whether this matters for any consumer.", "In the diff, only Uri.Builder.scheme(String) changes. The other Builder setters (for example opaquePart, authority and path) are not modified." ], "behavior_changes": [ "Uri.Builder.scheme() silently changes its input. Any \"://\" substring is dropped, so getScheme() and toString() of the built Uri differ from the string supplied. Apps that pass a scheme containing \"://\" will see different output.", "No new exception or error code is introduced. Null schemes behave as before.", "On Android 15 the follow-up changed replaceAll to replace, which its commit message describes as a performance change. Because \"://\" contains no regex metacharacters, the result is the same (general platform knowledge)." ], "preconditions": [ "A component builds a Uri with android.net.Uri.Builder using a scheme string that an untrusted party can influence.", "The privileged consumer that makes this an EoP per the bulletin is not shown in the material. Per index search, no relevant callers outside the test were returned." ], "per_major": { "14": "same fix: DO NOT MERGE cherry-pick e7af00cafb52 landed in android-security-14.0.0_r12 (replace() form plus UriTest.testSchemeSanitization). At android-security-14.0.0_r29, 8/8 lines of the patched region are present.", "15": "resolved in the android-15.0.0_r1 base. Commit 003800764d61 switched an earlier replaceAll(\"://\", \"\") to replace(\"://\", \"\"). At android-security-15.0.0_r17, 3/4 lines of the patched region are present. The material does not show why one line differs.", "16": "not affected (not listed by the bulletin). At android-security-16.0.0_r8, 8/8 lines of the patched region are present.", "17": "not affected (not listed by the bulletin). At android-security-17.0.0_r1, 8/8 lines of the patched region are present." }, "backport_notes": [ "This is a self-contained change to one method, Uri.Builder.scheme(), with no dependencies shown. Use the replace() form, as in the 14 backport and the 15 follow-up. The test needs android.platform.test.annotations.AsbSecurityTest to be available in FrameworksCoreTests (general platform knowledge).", "android.net.Uri lives in frameworks/base core rather than a mainline module, so the fix ships with the platform image (general platform knowledge)." ], "confidence": "medium", "unknowns": [ "Which system component or privileged consumer uses Builder-produced URIs in a way that turns the delimiter injection into EoP. The material only shows the library-level fix and the unit test.", "Why the Android 15 security tag reports only 3/4 lines of the patched region present.", "Whether Google considered that a single replace() call can leave a re-formed \"://\" for crafted inputs." ], "meta": { "generated": "2026-10-04", "author_model": "claude-fable-5-1", "review_model": "claude-opus-5-5", "review_corrections": 9, "note": "AI-generated from the bulletin, the fixing diffs and their code context, then checked claim by claim by a second model. Statements marked '(general platform knowledge)' are not taken from the material." } } } }, "15": { "counts": { "announced": 10, "certain": 10, "probable": 0, "not_published": 0, "not_covered": 0, "awaiting": 0 }, "advisories": [ { "cve": "CVE-2024-32896", "osv_id": "ASB-A-324321147", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/build/soong", "sha": "7ee98928ea1bae11b7e231b07024b26ec801921f", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/build/soong" ] }, { "cve": "CVE-2024-40650", "osv_id": "ASB-A-293199910", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "092668676af741719d50ac0f121a8f8461aa21ad", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40652", "osv_id": "ASB-A-327749022", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "70a5a0fd353cc6203d2926627de93786155ae5bc", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40654", "osv_id": "ASB-A-333364513", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "a339d8ea9a16311a0d42902c59dc3a775e3532a2", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40655", "osv_id": "ASB-A-300904123", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/services/Telecomm", "sha": "9d97cd5825066ac8e15bbf97f6755663c5341afb", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/services/Telecomm" ] }, { "cve": "CVE-2024-40656", "osv_id": "ASB-A-329058967", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "ID" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/services/Telecomm", "sha": "8c619f58c00047ab0ec687cd231bf93a08db6d55", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/services/Telecomm" ] }, { "cve": "CVE-2024-40657", "osv_id": "ASB-A-341886134", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/packages/apps/Settings", "sha": "2cb9b10ed97b1b9b29661115789605a762f3c2ef", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/packages/apps/Settings" ] }, { "cve": "CVE-2024-40658", "osv_id": "ASB-A-329641908", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/frameworks/av", "sha": "899a582bba8891968a87f425228b3080514240b0", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/frameworks/av" ] }, { "cve": "CVE-2024-40659", "osv_id": "ASB-A-336976105", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "DoS" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/frameworks/base", "sha": "fb65afa14cddf8018704ab85c08beeffcf471638", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/frameworks/base" ] }, { "cve": "CVE-2024-40662", "osv_id": "ASB-A-261721900", "source": "osv", "announced": "2024-09-01", "severity": "High", "types": [ "EoP" ], "status": "resolved", "method": [ "base" ], "confidence": "certain", "first_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "last_fix": { "tag": "android-15.0.0_r1", "date": "2024-09-03", "provenance": "base_release" }, "public_commits": [ { "project": "platform/frameworks/base", "sha": "003800764d6180cddb7202e4e46e7bd48b71d4b9", "tag": "android-15.0.0_r1", "provenance": "base_release", "method": "base", "confidence": "certain", "evidence": "fix in the base release, inherited by the security line", "similarity": null } ], "n_public_commits": 1, "projects": [ "platform/frameworks/base" ] } ], "tags": [], "unannounced": [], "coverage": { "n_ingested_tags": 18, "first_ingested_tag": "android-security-15.0.0_r1", "latest_ingested_tag": "android-security-15.0.0_r18", "window_base_tag": "android-15.0.0_r1", "window_start": "2024-09-03", "partial_tags": [] }, "platform_update_tags": {}, "briefs": {} }, "16": { "counts": { "announced": 0, "certain": 0, "probable": 0, "not_published": 0, "not_covered": 0, "awaiting": 0 }, "advisories": [], "tags": [], "unannounced": [], "coverage": { "n_ingested_tags": 9, "first_ingested_tag": "android-security-16.0.0_r1", "latest_ingested_tag": "android-security-16.0.0_r9", "window_base_tag": "android-16.0.0_r2", "window_start": "2025-06-10", "partial_tags": [] }, "platform_update_tags": {}, "briefs": {} }, "17": { "counts": { "announced": 0, "certain": 0, "probable": 0, "not_published": 0, "not_covered": 0, "awaiting": 0 }, "advisories": [], "tags": [], "unannounced": [], "coverage": { "n_ingested_tags": 2, "first_ingested_tag": "android-security-17.0.0_r1", "latest_ingested_tag": "android-security-17.0.0_r2", "window_base_tag": "android-17.0.0_r1", "window_start": "2026-06-16", "partial_tags": [] }, "platform_update_tags": {}, "briefs": {} } }, "bulletin": { "url": "https://source.android.com/docs/security/bulletin/2024-09-01", "latest_version": "1.0", "latest_revision": { "version": "1.0", "date": "September 3, 2024", "notes": "Bulletin published" }, "revisions": [ { "version": "1.0", "date": "September 3, 2024", "notes": "Bulletin published" } ], "tracked_since": "2026-09-30", "changes_since_tracking": [], "out_of_scope_rows": { "Arm components": 1, "Imagination Technologies": 2, "Kernel": 1, "Qualcomm closed-source components": 7, "Qualcomm components": 12, "Unisoc components": 2 }, "note": "changes are only visible from `tracked_since`; earlier revisions of the bulletin cannot be reconstructed. Out-of-scope rows (vendor closed-source, kernel) have no public AOSP code to resolve." } }