CVE-2025-0096 AI-generated analysis

platform/hardware/st/nfc, st21nfc NFC HAL (polling loop / firmware log TLV handling, st21nfc/hal/hal_fwlog.cc)

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.

Enlarges the heap buffer allocated for the FieldOn/FieldOff TLV in handlePollingLoopData from 8 to 9 bytes so that the nine bytes written into it no longer overflow the allocation.

Root cause

In st21nfc/hal/hal_fwlog.cc:handlePollingLoopData, the T_fieldOn/T_fieldOff case allocated *NewTlv with malloc(8 * sizeof(uint8_t)) but then wrote nine bytes into it: a 3-byte header (type, flag, value_len) followed by value_len = 6 payload bytes at indices 3 through 8. The store to (*NewTlv)[8] therefore wrote one byte past the end of the 8-byte heap allocation on every FieldOn/FieldOff event.

How the fix works

• st21nfc/hal/hal_fwlog.cc:handlePollingLoopData, case T_fieldOn/T_fieldOff: the allocation is changed from malloc(8 * sizeof(uint8_t)) to malloc(9 * sizeof(uint8_t)), matching the 3-byte header plus value_len (0x06) bytes actually written (indices 0..8). No other logic changes; the writes themselves are unchanged.

Completeness

• The fix covers only the T_fieldOn/T_fieldOff branch; the allocation size now equals the number of bytes written (9).
• The sibling T_CERxError/T_CERx branch (tlv_size derived from tlvBuffer[1] - 2, clamped to a minimum of 8 or forced to 9 by the ST54J work-around) is not touched by this commit; its allocation and writes are not shown in the material, so its correctness cannot be judged here.
• The function still reads tlvBuffer[data_len - 4 .. data_len - 1] for the timestamp without a visible check in the function that data_len >= 4; this commit does not address input length validation, only the output buffer size.
• The malloc return value is still not checked for NULL in the shown code.

Behavior changes

• None observable beyond the allocation being one byte larger; the produced TLV content is identical.

Per major

• Android 14: not affected: not listed by the bulletin; st21nfc/hal/hal_fwlog.cc is absent at android-security-14.0.0_r29.
• Android 15: same fix: commit 58728fc8363b in android-security-15.0.0_r5 (cherry-pick of b7056d70f2cd); at android-security-15.0.0_r17 the code shows malloc(9 * sizeof(uint8_t)) with writes to indices 0..8.
• Android 16: not affected: not listed by the bulletin; at android-security-16.0.0_r8, 5/6 lines of the patched region are present (whether the allocation reads 9 is not shown).
• Android 17: not affected: not listed by the bulletin; at android-security-17.0.0_r1, 5/6 lines of the patched region are present (whether the allocation reads 9 is not shown).

Unknowns

• The caller of handlePollingLoopData and how the resulting *NewTlv is consumed/freed are not shown.
• Whether the T_CERx/T_CERxError branch allocates a buffer consistent with its writes is not visible in the material.
• The exact trigger and why the bulletin classifies it as EoP are not shown.
• Which line of the patched region is missing at the Android 15/16/17 tags (5/6 match), and whether 16/17 carry the 9-byte allocation.

Back to February 2025 · Findings