CVE-2026-28618 AI-generated analysis
platform/external/libopenapv, APV decoder (src/oapv.c)
Adds a check in libopenapv's dec_frm_prepare that returns OAPV_ERR_INVALID_ARGUMENT when the plane-0 width or height of the output image buffer supplied by the caller is smaller than the frame dimensions in the Frame PBU header, preventing a heap buffer overflow.
Root cause
The caller allocates the decoder's output image buffer (oapv_imgb_t *imgb) from the AU_INFO dimensions. dec_frm_prepare in src/oapv.c, however, takes the frame dimensions from the Frame PBU header (ctx->fh.fi.frame_width / frame_height) and sets ctx->w / ctx->h from them without checking that imgb is large enough. Per the commit message, a Frame PBU that declares larger dimensions than AU_INFO leads to a heap buffer overflow on that buffer. The material does not show which function performs the out-of-bounds access.
How the fix works
- src/oapv.c:dec_frm_prepare: at function entry, before ctx->imgb is assigned and before imgb_addref is called, compare imgb->w[0] against ctx->fh.fi.frame_width and imgb->h[0] against ctx->fh.fi.frame_height. If either buffer dimension is smaller, return OAPV_ERR_INVALID_ARGUMENT, so nothing is decoded into the undersized buffer.
- Because the check comes before imgb_addref, the early return does not leak a reference on the image buffer.
- Single-commit fix. The Android 17 commit (7c797fcb63c8) contains the identical hunk at a slightly different line offset.
Completeness
- Covers a mismatch between the Frame PBU frame_width/frame_height and the luma (plane 0) dimensions of the supplied imgb.
- Only imgb->w[0] and imgb->h[0] are checked. Chroma plane dimensions (w[1], w[2], h[1], h[2]) are not validated directly. Whether that matters depends on how the caller derives chroma plane sizes, which the material does not show.
- The check compares against the unaligned frame_width/frame_height, while ctx->w and ctx->h are rounded up to OAPV_MB_W / OAPV_MB_H. The material does not show whether the block-to-image functions clip to the imgb dimensions, so the effect of the alignment slack cannot be determined from the diff.
- The fix does not check that the color/chroma format of imgb (OAPV_CS_GET_FORMAT(imgb->cs)) matches ctx->fh.fi.chroma_format_idc. That path is untouched.
Behavior changes
- dec_frm_prepare now returns OAPV_ERR_INVALID_ARGUMENT when the Frame PBU dimensions exceed the plane-0 dimensions of the supplied output buffer, and such frames are no longer decoded.
Per major
- Android 14: not affected: not listed by the bulletin, and platform/external/libopenapv is not present in android-security-14.0.0_r29
- Android 15: not affected: not listed by the bulletin, and platform/external/libopenapv is not present in android-security-15.0.0_r17
- Android 16: same fix: commit b40bceb14205 in android-security-16.0.0_r8, 3/3 lines of the patched region present
- Android 17: same fix: commit 7c797fcb63c8 in android-security-17.0.0_r1 with the identical hunk, 3/3 lines of the patched region present
Unknowns
- How the caller (e.g. C2SoftApvDec) sizes the chroma planes of imgb relative to plane 0, and whether the block-to-image functions clip writes to the imgb dimensions.
- Which function performs the out-of-bounds access, and whether it is a read or a write.
- How the OAPV_ERR_INVALID_ARGUMENT return propagates through the public decode API to callers such as C2SoftApvDec.
- Whether the 16-qpr2 and 17-next branches listed by the bulletin carry the same commit (not shown in the material).