CVE-2026-28583 AI-generated analysis
platform/system/media, camera metadata (camera/src/camera_metadata.c)
Corrects validate_camera_metadata_structure in system/media camera_metadata.c so that entry_capacity is converted from an entry count to bytes (times sizeof(camera_metadata_buffer_entry_t)), with an overflow check, before verifying that the entry region ends at or before data_start.
Root cause
In validate_camera_metadata_structure, the end of the entry region was computed as header->entries_start + header->entry_capacity and compared to header->data_start. But entry_capacity is the number of camera_metadata_buffer_entry_t entries the buffer can hold, as the struct layout comment at lines 72-80 describes, not a byte count. So the check accepted headers where entry_capacity * sizeof(camera_metadata_buffer_entry_t) was larger than the space between entries_start and data_start. Per the commit message, a crafted camera_metadata buffer could pass validation and cause an out-of-bounds write, which crashed cameraserver.
How the fix works
- camera/src/camera_metadata.c:validate_camera_metadata_structure: adds a pre-check that rejects header->entry_capacity > (metadata_size_t)~0 / sizeof(camera_metadata_buffer_entry_t), with a new ALOGE and CAMERA_METADATA_VALIDATION_ERROR. This stops the multiplication from wrapping in metadata_size_t, which is 32-bit per the _Static_assert.
- camera/src/camera_metadata.c:validate_camera_metadata_structure: computes metadata_size_t entries_capacity_bytes = sizeof(camera_metadata_buffer_entry_t) * header->entry_capacity and uses it in entries_end = header->entries_start + entries_capacity_bytes.
- camera/src/camera_metadata.c:validate_camera_metadata_structure: splits the old combined condition into two checks. The first is entries_end < header->entries_start (addition overflow, with a new log message). The second is entries_end > header->data_start (range check, with the existing log message now printing entries_end). Both return CAMERA_METADATA_VALIDATION_ERROR.
- camera/src/camera_metadata.c:struct camera_metadata: adds comments that document entry_capacity as a number of entries and data_capacity as a number of data bytes (no functional change).
Completeness
- The fix covers the relationship between entry_capacity and data_start in validate_camera_metadata_structure, including multiplication and addition overflow.
- Only the entry-region check changes. The data_capacity/data_start checks and the rest of the function are not in the diff or the material, so their state cannot be judged here.
- The fix is only in the validator. The code paths that write entries are not changed, so protection depends on callers running validate_camera_metadata_structure on untrusted buffers (see the callers in preconditions).
Behavior changes
- Stricter validation: buffers whose entry_capacity, counted in entries, does not fit between entries_start and data_start now fail with CAMERA_METADATA_VALIDATION_ERROR instead of passing.
- Buffers with entry_capacity greater than (metadata_size_t)~0 / sizeof(camera_metadata_buffer_entry_t) are rejected with a new 'Entry capacity ... is too large' log.
- New 'Entry start ... + capacity bytes ... overflows' log line. The existing 'should be <= data start' log now prints the byte-based entries_end.
Per major
- Android 14: same fix: platform/system/media a9dc2a964e84 in android-security-14.0.0_r29, patched region fully present (8/8).
- Android 15: same fix: platform/system/media 9b4fe9dce95b in android-security-15.0.0_r17, identical diff and blob indices (e0c1cadb..0935461a), patched region fully present (8/8).
- Android 16: same fix: platform/system/media 312249da098c in android-security-16.0.0_r8, identical hunks on a different file revision (1f09d5b1..95116f6c), patched region fully present (8/8).
- Android 17: not affected per the bulletin (not listed). The patched region is fully present (8/8) at android-security-17.0.0_r1.
Unknowns
- Which caller or IPC path delivered the crafted metadata in the reported case, and the specific write path (the commit only mentions an out-of-bounds write and a cameraserver crash).
- Whether the surrounding data_start/data_capacity checks in validate_camera_metadata_structure are correct. They are outside the diff and not shown.
- How allocate/place_camera_metadata lay out entries_start and data_start, and so whether all legitimately created buffers still pass (the allocation code is not shown).
- Whether the change is also shipped in a vendor or HAL copy of the camera metadata code.