libheif: integer underflow out-of-bounds read crash via crafted HEIF stsc box

# Root Cause Analysis: CVE-2026-32738

## Summary

`libheif` versions 1.21.2 and below contain an integer underflow vulnerability in the `Chunk` constructor during HEIF/HEIC sequence file parsing. When a crafted file's `stsc` (sample-to-chunk) box specifies `samples_per_chunk = 0`, the unsigned 32-bit expression `first_sample + num_samples - 1` underflows to `UINT32_MAX`. This causes all sequence samples to be mapped to an empty chunk. Subsequent sample access attempts to read index 0 of an empty `std::vector`, resulting in a guaranteed null-page read / SIGSEGV crash — a denial of service against any application that decodes attacker-supplied HEIF sequence files.

## Impact

- **Package**: `libheif` (C++ library for HEIF/HEIC/AVIF)
- **Affected versions**: `<= 1.21.2`
- **Fixed version**: `1.22.0`
- **Risk level**: Medium (CVSS 3.1 base 6.5)
- **Consequences**: Denial of service via process crash (SIGSEGV). Any application using libheif to decode HEIF sequences is exposed.

## Root Cause

The vulnerability occurs in two locations in `libheif/sequences/chunk.cc`:

1. **Missing validation in `Box_stsc::parse()`**: The `samples_per_chunk` field is read as a raw `uint32_t` from the file with no rejection of the value `0`, even though ISO 14496-12 requires this field to be ≥ 1.

2. **Unsigned integer underflow in `Chunk::Chunk()` (line ~82)**:
   ```cpp
   m_last_sample = first_sample + num_samples - 1;
   ```
   When `num_samples = 0` and `first_sample = 0`, this evaluates to `0 + 0 - 1 = UINT32_MAX` due to unsigned underflow. The `m_sample_ranges` vector remains empty because the `for (i < 0)` loop never executes.

3. **Out-of-bounds read in `Chunk::get_data_extent_for_sample()` (line ~112)**:
   ```cpp
   extent.set_file_range(m_ctx->get_heif_file(),
                         m_sample_ranges[n - m_first_sample].offset,
                         m_sample_ranges[n - m_first_sample].size);
   ```
   Since `m_sample_ranges` is empty, accessing index `0` dereferences a null pointer (empty vector `begin()`), causing a SEGV.

4. **All samples mapped to the empty chunk**: In `Track::init_sample_timing_table()`, the loop condition `i > m_chunks[current_chunk]->last_sample_number()` is always false because `last_sample_number()` returns `UINT32_MAX`. Consequently, every sample is assigned to chunk 0, ensuring the crash is triggered on the first frame access.

The fix commit is `edc12502` ("Validate stsc sample coverage against stsz/stts") in the `v1.21.2..v1.22.0` history, which adds a validation check in `Track::load()` ensuring the total samples covered by `stsc` entries match the `stsz`/`stts` sample count. Additionally, `Box_stsc::parse()` or related logic in 1.22.0 explicitly rejects `samples_per_chunk = 0` with the controlled error message: `'stsc' box with zero samples per chunk entry`.

## Reproduction Steps

The reproduction script is at `repro/reproduction_steps.sh`.

What the script does:
1. Installs build dependencies (`cmake`, `build-essential`, `git`, `libjpeg-dev`).
2. Clones `libheif` from GitHub.
3. Builds the **vulnerable** version `v1.21.2` and the **fixed** version `v1.22.0` with minimal codecs (only JPEG decoder and uncompressed codec enabled).
4. Creates two tiny JPEG images and uses `heif-enc` to generate a valid 2-frame HEIF sequence.
5. Binary-patches the `stsc` box in the sequence file, changing `samples_per_chunk` from `2` to `0`.
6. Compiles a small C harness that opens the file and calls `heif_track_decode_next_image()`.
7. Runs the harness against both library versions and captures logs.

Expected evidence:
- **Vulnerable (1.21.2)**: The harness crashes with `SIGSEGV` (exit code 139 / signal 11). AddressSanitizer builds show a clear null-page read in `Chunk::get_data_extent_for_sample()`.
- **Fixed (1.22.0)**: The harness returns a controlled decode error: `Invalid input: Unspecified: 'stsc' box with zero samples per chunk entry.` No crash occurs.

## Evidence

Log files generated by the reproduction script:

- `logs/vulnerable.log`:
  ```
  === Testing vulnerable libheif v1.21.2 ===
  Track handler: pict
  Vulnerable exit code: 139
  ```
  Exit code 139 = 128 + 11, confirming a `SIGSEGV` (signal 11) crash.

- `logs/fixed.log`:
  ```
  === Testing fixed libheif v1.22.0 ===
  Error reading file: Invalid input: Unspecified: 'stsc' box with zero samples per chunk entry.
  Fixed exit code: 1
  ```
  The fixed version rejects the malformed file with a clean, controlled error instead of crashing.

AddressSanitizer output from the ASAN-instrumented vulnerable build (captured during verification):
```
DEBUG: get_data_extent_for_sample called with n=0, m_first_sample=0, m_last_sample=4294967295, vector_size=0
AddressSanitizer:DEADLYSIGNAL
==12262==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008
    #0 Chunk::get_data_extent_for_sample(unsigned int) const
    #1 Track_Visual::decode_next_image_sample(heif_decoding_options const&)
    #2 heif_track_decode_next_image
```

## Recommendations / Next Steps

1. **Upgrade to libheif 1.22.0 or later** — the fix adds explicit validation of `stsc` entries against `stsz`/`stts` sample counts and rejects zero `samples_per_chunk` values.
2. **Add regression tests** — the reproduction file and harness can be incorporated into CI to prevent reintroduction of the bug.
3. **Harden parsing** — consider adding more defensive checks in `Box_stsc::parse()` and `Chunk::Chunk()` to reject invalid zero values immediately, rather than relying on downstream validation.

## Additional Notes

- **Idempotency**: `repro/reproduction_steps.sh` was run twice consecutively; both runs produced identical results (vulnerable crash, fixed clean rejection) and exited with code 0.
- **Edge cases**: The crash is guaranteed as long as any accessed sample maps to a chunk with `samples_per_chunk = 0`. The reproduction uses a minimal 2-frame sequence, but the vulnerability scales to any sequence file where at least one `stsc` entry has a zero sample count.