CVE-2024-43080 AI-generated analysis
platform/packages/apps/Settings, users / app restrictions (AppRestrictionsFragment.RestrictionsResultReceiver)
In Settings' AppRestrictionsFragment, the custom restrictions Intent received from an app's broadcast result extras is no longer launched as the raw deserialized object; startActivityForResult is given a fresh copy (new Intent(restrictionsIntent)) instead.
Root cause
RestrictionsResultReceiver.onReceive in src/com/android/settings/users/AppRestrictionsFragment.java reads an Intent (CUSTOM_RESTRICTIONS_INTENT) out of the result extras Bundle returned by the target app's restrictions broadcast and, when invokeIfCustom is set and the fragment is resumed, passed that exact object to AppRestrictionsFragment.this.startActivityForResult(restrictionsIntent, requestCode). Settings therefore launched an Intent object deserialized from another app's result rather than one it constructed itself. The commit message states only that a copy must be used instead of the raw Intent ("See bug"); the bug text is not part of the material.
How the fix works
- src/com/android/settings/users/AppRestrictionsFragment.java : RestrictionsResultReceiver.onReceive: the single changed line replaces startActivityForResult(restrictionsIntent, requestCode) with startActivityForResult(new Intent(restrictionsIntent), requestCode), so the launched Intent is a copy constructed by Settings via the Intent copy constructor rather than the Parcelable object taken from the result Bundle.
- In the android-security-14.0.0_r29 code the region differs: assertSafeToStartCustomActivity(restrictionsIntent) creates new Intent(intent), resolves it with mPackageManager.resolveActivity, throws SecurityException unless the resolved activity's package equals packageName, and returns a vetted copy; onReceive then launches vettedIntent. This also launches a Settings-created copy rather than the raw object.
Completeness
- The fix covers the only startActivityForResult call in the shown region (custom restrictions activity launch in RestrictionsResultReceiver.onReceive).
- The committed change is only the copy; it does not add or change any resolution or package check. The vetting visible at r29 (assertSafeToStartCustomActivity returning vettedIntent) is present in that tree, but the material does not show its form at r14.
- The other branch of onReceive (restrictions != null && restrictionsIntent == null -> setApplicationRestrictions) is untouched and does not launch an Intent.
Behavior changes
- The Intent passed to startActivityForResult is a Settings-constructed copy instead of the deserialized object; the diff adds no new error path or check.
Per major
- Android 14: same fix: commit 26ce013dfd7e (Change-Id Id74e4b7ae261f2916eedaef04a679f83409a4b67, cherry-picked twice) in android-security-14.0.0_r14. At android-security-14.0.0_r29 the region differs (3/4 lines present): the launch uses vettedIntent returned by assertSafeToStartCustomActivity, which makes the copy internally.
- Android 15: not affected per bulletin; at android-security-15.0.0_r17, 3/4 lines of the patched region are present (exact form not shown).
- Android 16: not affected per bulletin; at android-security-16.0.0_r8, 3/4 lines of the patched region are present (exact form not shown).
- Android 17: not affected per bulletin; at android-security-17.0.0_r1, 3/4 lines of the patched region are present (exact form not shown).
Unknowns
- The exact reason a copy is required (what differs between the raw deserialized Intent and its copy at launch) is only in bug 330722900, which is not provided.
- Whether assertSafeToStartCustomActivity existed, and in what form, at android-security-14.0.0_r14, and which later commit changed the launch to vettedIntent.
- The exact code form of the patched region in 15, 16 and 17.