CVE-2026-28652 AI-generated analysis

platform/packages/modules/Uwb, ranging service (com.android.server.ranging.RangingServiceImpl, IRangingAdapter.Stub)

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

Adds enforceRangingPermission() to five out-of-band (OOB) ranging Binder entry points in RangingServiceImpl (oobDataReceived, deviceOobDisconnected, deviceOobReconnected, deviceOobClosed, registerOobSendDataListener). Before the fix these methods passed calls to RangingServiceManager without any permission check.

Root cause

RangingServiceImpl extends IRangingAdapter.Stub and implements the Binder interface of the ranging service. In the shown region, addRawDevice, addOobDevice, removeDevice and stopRanging call enforceRangingPermission() before passing the call on to mRangingInjector.getRangingServiceManager(), and so does the method that calls RangingServiceManager.reconfigureInterval. The five OOB methods oobDataReceived, deviceOobDisconnected, deviceOobReconnected, deviceOobClosed and registerOobSendDataListener had no such check: they passed caller input (OobHandle, data, IOobSendDataListener) to RangingServiceManager without requiring the ranging permission. The bulletin classifies the result as information disclosure (ID), severity High.

How the fix works

• ranging/service/java/com/android/server/ranging/RangingServiceImpl.java:oobDataReceived - enforceRangingPermission() is now the first statement, before the call to RangingServiceManager.oobDataReceived(oobHandle, data).
• RangingServiceImpl.java:deviceOobDisconnected, deviceOobReconnected, deviceOobClosed - the same enforceRangingPermission() call is added before each call to the matching RangingServiceManager method.
• RangingServiceImpl.java:registerOobSendDataListener - enforceRangingPermission() is added before RangingServiceManager.registerOobSendDataListener(oobSendDataListener).
• The fix reuses the enforceRangingPermission() helper that the other methods of the class already use. The diff adds no new helper, AIDL change or manifest change. It is a single commit with 5 insertions.

Completeness

• Covers all five OOB methods named in the commit message. After the fix, every method visible in the shown region of RangingServiceImpl (lines 74-132) calls enforceRangingPermission().
• Methods of RangingServiceImpl above line 74 are not shown, so the code cannot confirm that every IRangingAdapter method is now gated.
• The fix adds only a caller permission check. It does not validate the OobHandle or data payload, and it does not check that the OobHandle belongs to the calling uid. RangingServiceManager itself is unchanged.

Behavior changes

• Callers without the permission checked by enforceRangingPermission() now fail at that check in the five OOB Binder methods, in the same way as in the other gated methods, and the call is no longer passed to RangingServiceManager. The body of the helper (and so the exact exception) is not shown.
• No change for callers that already hold the permission.

Per major

• Android 14: Not affected per the bulletin. Code absent: RangingServiceImpl.java does not exist at android-security-14.0.0_r29.
• Android 15: Not affected per the bulletin. Code absent: RangingServiceImpl.java does not exist at android-security-15.0.0_r17.
• Android 16: Same fix: commit 618d9adfcd65 in android-security-16.0.0_r8, a cherry-pick of internal changes 1a1f98ef and d9680b2f (Change-Id I9d2f34330258d00b4d19e57f330c58fdde021846). 8/8 lines of the patched region present.
• Android 17: Same fix: commit 3be00374c294 in android-security-17.0.0_r1. The hunk is identical but starts at a different line (113 instead of 102). 8/8 lines present.

Unknowns

• The body of enforceRangingPermission() and the exact permission string it checks are not in the material.
• The material does not show which internal state RangingServiceManager.oobDataReceived and the deviceOob* methods change, or what data an IOobSendDataListener receives. The information-disclosure path stated by the bulletin cannot be traced from the diff alone.
• Whether the methods of RangingServiceImpl outside the shown region were already gated.
• What the second internal cherry-pick (d9680b2f) contained beyond what was merged here. The AOSP commit shows only the five insertions.
• Whether this fix reaches devices through a mainline module update or through a platform OTA.

Back to September 2026 · Findings