CVE-2026-55294 AI-generated analysis

platform/external/libhevc, HEVC software decoder (libhevcdec), TU data sizing in decoder/ihevcd_utils.c

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

In libhevc's ihevcd_get_tu_data_size(), the tu_map part of the TU data size is now budgeted with num_tu (luma plus chroma TUs) instead of num_luma_tu, so the size matches the space the initialization logic consumes.

Root cause

ihevcd_get_tu_data_size() computes the TU data size as the sum of several sub-regions: CTB start indices, tu_map, the tu_t array, coded-subblock/scan_idx bytes and coefficient data. Every per-TU sub-region except tu_map was sized with num_tu = num_luma_tu + num_chroma_tu. tu_map was sized with num_luma_tu * sizeof(UWORD8) only. According to the commit message, the initialization logic consumes tu_map space for both luma and chroma TUs, so the tu_map budget was too small and a heap buffer overflow resulted. The writer code is not in the material.

How the fix works

• decoder/ihevcd_utils.c:ihevcd_get_tu_data_size: 'tu_data_size += num_luma_tu * sizeof(UWORD8);' (the tu_map budget) becomes 'tu_data_size += num_tu * sizeof(UWORD8);'. num_tu = num_luma_tu + num_chroma_tu is already computed earlier in the function. The returned size grows by num_chroma_tu bytes, which matches the other per-TU sub-regions.
• The code that writes tu_map is not changed; the fix is only on the sizing side. The file mode also changes from 100755 to 100644, which has no functional effect.

Completeness

• The fix covers the one mismatch visible in the diff, the tu_map budget. After the change every sub-region in ihevcd_get_tu_data_size() is scaled by num_tu, except the per-CTB index array, which is scaled by num_ctb + 1.
• No bounds check is added on the write side. The tu_map initialization code is not in the material, so it cannot be judged whether the consumer makes any other size assumptions.

Behavior changes

• The size returned by ihevcd_get_tu_data_size() grows by num_chroma_tu bytes (num_luma_tu >> 1), so decoder memory use rises slightly. There are no new error codes, API changes or stricter input validation.

Per major

• Android 14: same fix: platform/external/libhevc d9977ef8294a in android-security-14.0.0_r29, one-line hunk in decoder/ihevcd_utils.c (Change-Id I8ff89026f66addf34b18dbedf9001db292db8fe9).
• Android 15: same fix: platform/external/libhevc c43bbf882f97 in android-security-15.0.0_r17, identical hunk.
• Android 16: same fix: platform/external/libhevc 5492b022e4d6 in android-security-16.0.0_r8, identical hunk (same pre- and post-image blob ids as Android 15).
• Android 17: same fix: platform/external/libhevc 9aa38f2733f4 in android-security-17.0.0_r1, identical hunk.

Unknowns

• The code that initializes or writes tu_map is not in the material. Its function name, the exact overrun size and the triggering stream conditions are known only from the commit message.
• The callers of ihevcd_get_tu_data_size() and how the buffer is allocated are not shown.
• What memory lies next to the overrun and the practical impact beyond the bulletin's High / EoP rating are not shown.

Back to September 2026 · Findings