CVE-2026-55277 AI-generated analysis
platform/packages/modules/Nfc, NfcNci JNI layer (NfcNci/nci/jni/RoutingManager.cpp, RoutingManager)
Adds a bounds check in RoutingManager::checkUiccListenConfigNeeded so a new UICC listen configuration is only appended to mNfceeListenConfig.config when nb_config is below NFA_EE_MAX_EE_SUPPORTED, otherwise it logs an error and returns false.
Root cause
In NfcNci/nci/jni/RoutingManager.cpp, RoutingManager::checkUiccListenConfigNeeded searches mNfceeListenConfig.config[] for an entry whose nfcee_id matches eeHandle. When no entry is found, it writes nfcee_id and tech_mask into mNfceeListenConfig.config[mNfceeListenConfig.nb_config] and increments nb_config without checking nb_config against NFA_EE_MAX_EE_SUPPORTED, the maximum number of supported execution environments. Per the commit message, exceeding that maximum allowed an out-of-bounds write, potentially corrupting adjacent synchronization primitives and causing crashes or deadlocks in the NFC system service.
How the fix works
- NfcNci/nci/jni/RoutingManager.cpp:RoutingManager::checkUiccListenConfigNeeded: inside the `if (!found)` branch, before the append, a new check `if (mNfceeListenConfig.nb_config >= NFA_EE_MAX_EE_SUPPORTED)` logs an error with LOG(ERROR) ("Exceeded max EE supported count") and returns false. When the limit is reached, the writes to config[nb_config].nfcee_id / .tech_mask and the nb_config++ therefore never execute.
- The existing path (entry found, tech_mask updated in place) is unchanged. The `found` loop iterates only up to nb_config, which the new check now keeps bounded at NFA_EE_MAX_EE_SUPPORTED.
- The commit message says a unit test was added (atest RoutingManagerTest), but this cherry-pick touches only RoutingManager.cpp (1 file, 5 insertions). The test is not part of this commit as shown.
Completeness
- Covers the single append site in checkUiccListenConfigNeeded, which is the only place in the shown context that grows mNfceeListenConfig.nb_config.
- When the limit is reached, the function returns false, the same value it returns when no change is made. Apart from the error log, the new EE is not tracked in the listen config, and no other handling (e.g. eviction or replacement) is added.
- No other writers of mNfceeListenConfig are shown in the material, so the code provided does not show whether other sites index config[] with an unchecked value.
Behavior changes
- When mNfceeListenConfig already holds NFA_EE_MAX_EE_SUPPORTED entries and an unknown eeHandle arrives, the function now logs an ERROR and returns false instead of writing out of bounds. The new EE's listen config is not recorded.
- No change in behavior when the count is below the limit or when the eeHandle is already present.
Per major
- Android 14: not affected per the bulletin; the platform/packages/modules/Nfc project is not present in android-security-14.0.0_r29 (code absent).
- Android 15: not affected per the bulletin; the project is not present in android-security-15.0.0_r17 (code absent).
- Android 16: not affected per the bulletin (Android 16 is not listed; the bulletin does list 16-qpr2). At android-security-16.0.0_r8, 0/2 lines of the patched region are present.
- Android 17: resolved: same fix, commit 8181cc81e300 in android-security-17.0.0_r1 (cherry-pick of b19f65e0b8b0, Change-Id I7d30e4f68b62858056ae2f50cc5676886057ec54); 2/2 patched lines present.
Unknowns
- Which callers of checkUiccListenConfigNeeded feed eeHandle, and whether the EE count can be influenced from outside the NFC service (the material does not show the call chain or the trigger).
- What the 'adjacent synchronization primitives' are, and the declared size of mNfceeListenConfig.config (the member layout and headers are not shown).
- The fix status of the 16-qpr2 branch (listed by the bulletin) and whether the vulnerable code exists at android-security-16.0.0_r8.
- The unit test mentioned in the commit message (RoutingManagerTest) is not in this diff; whether it landed separately is not shown.