CVE-2023-40106 AI-generated analysis

platform/frameworks/base, Notification / NotificationManagerService

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

Replaces Notification.setAllowlistToken(null) with a new clearAllowlistToken() that also nulls the allowlist token on the nested publicVersion Notification before NotificationManagerService returns an app's own notifications to it.

Root cause

NotificationManagerService.sanitizeSbn clones a Notification and calls setAllowlistToken(null) so that an app retrieving its own notifications does not get back the background allowlist token (the commit message says this token lets the app fire its own PendingIntent to launch activities from the background). The Notification.publicVersion field is itself a Notification carrying its own mAllowlistToken, and that nested token was left intact in the returned object.

How the fix works

• core/java/android/app/Notification.java: the @hide setter setAllowlistToken(IBinder) is replaced by clearAllowlistToken(), which sets mAllowlistToken = null and, if publicVersion != null, recursively calls publicVersion.clearAllowlistToken().
• services/core/java/com/android/server/notification/NotificationManagerService.java (sanitizeSbn, called for the calling package's notifications, including snoozed and enqueued ones, per the r29 context): the call notification.setAllowlistToken(null) is changed to notification.clearAllowlistToken(), so both the outer notification and its publicVersion lose the token before the StatusBarNotification is built and returned.

Completeness

• The diff changes the sanitizeSbn call site and clears the token on the outer Notification and, recursively, on any chain of publicVersion objects.
• Only publicVersion is handled. The diff does not show whether any other Notification sub-object can carry an allowlist token, and no other return path is touched by this commit.
• At android-security-14.0.0_r29 the sanitizeSbn call site reads notification.overrideAllowlistToken(null) rather than clearAllowlistToken(). The body of overrideAllowlistToken is not in the material, so the material cannot show whether that later API keeps the publicVersion handling.

Behavior changes

• Notifications returned through sanitizeSbn now have a null allowlist token on publicVersion as well as on the top-level Notification.
• The @hide method Notification.setAllowlistToken(IBinder) is removed and replaced by clearAllowlistToken(). Any other caller of the old setter would fail to compile (the diff shows none).

Per major

• Android 14: same fix: commit 7ac1135a7f85 in android-security-14.0.0_r2 (bug 278558814). At android-security-14.0.0_r29 the call site has since changed to notification.overrideAllowlistToken(null) (6/8 patched lines present).
• Android 15: not affected per the bulletin. At android-security-15.0.0_r17, 6/8 lines of the patched region are present.
• Android 16: not affected per the bulletin. At android-security-16.0.0_r8, 6/8 lines of the patched region are present.
• Android 17: not affected per the bulletin. At android-security-17.0.0_r1, 6/8 lines of the patched region are present.

Unknowns

• Body of Notification.overrideAllowlistToken, used at android-security-14.0.0_r29, and whether it recurses into publicVersion.
• Whether other Notification fields besides publicVersion can carry an allowlist token.
• Whether other service paths return Notification objects to apps without going through sanitizeSbn.
• Name of the binder method that calls sanitizeSbn and the full set of its call sites.

Back to November 2023 · Findings