Skip to content

fix(avif): check alpha and primary picture dimensions match - #3098

Merged
197g merged 1 commit into
image-rs:mainfrom
MsfPablo:fix/avif-alpha-dimension-check
Aug 5, 2026
Merged

fix(avif): check alpha and primary picture dimensions match#3098
197g merged 1 commit into
image-rs:mainfrom
MsfPablo:fix/avif-alpha-dimension-check

Conversation

@MsfPablo

@MsfPablo MsfPablo commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #3084. The primary and alpha pictures in an AVIF file are decoded by separate dav1d instances, so nothing guarantees they agree on size. read_image zipped the primary buffer against the alpha plane without checking this — a malformed file with mismatched primary/alpha dimensions would silently truncate compositing to the shorter of the two, instead of erroring on the malformed input.

The 16-bit path (process_16bit_picture) had the same underlying gap in a different shape: it reshapes the alpha plane via transmute_y_plane16 using the primary picture's width/height, without ever confirming the alpha picture's actual dimensions match those.

Fix

Added a dimension check alongside the existing pixel_layout check, in both the 8-bit and 16-bit alpha-compositing paths, returning a new AvifDecoderError::AlphaPlaneSize { alpha, primary } variant on mismatch instead of silently truncating.

Test plan

  • cargo build --features avif -p image and cargo test --features avif -p image — clean, existing truncate_avif test still passes, no regression
  • cargo fmt -p image -- --check and cargo clippy --features avif -p image -- -D warnings — both clean

I was not able to add a dedicated regression test for the mismatch case itself: reproducing it requires a malformed AVIF container with two AV1 sub-images (primary + alpha) at different resolutions, and I didn't have a reliable way to construct or find such a fixture. Rather than fabricate something that doesn't actually exercise the mismatch path, I'm disclosing that gap here — happy to add one if pointed at an existing fixture-generation pattern for this codec, or if a maintainer can supply/generate a suitable malformed sample.

Disclosure

Per this org's CONTRIBUTING.md LLM policy: this PR was substantially developed with AI assistance (Claude), under my direction and review — I investigated the reported root cause myself, wrote/reviewed the fix, and ran the verification above locally before opening this.

The primary and alpha pictures in an AVIF file are decoded by separate
dav1d instances, so nothing guarantees they agree on size. read_image
zipped the primary buffer against the alpha plane without checking
this, so a malformed file with mismatched dimensions would silently
truncate compositing to the shorter of the two instead of erroring on
the malformed input. The 16-bit path had the same gap: it reshaped the
alpha plane using the primary picture's width/height without
confirming the alpha picture actually has those dimensions.

Add a dimension check alongside the existing pixel_layout check in
both the 8-bit and 16-bit compositing paths, returning a new
AvifDecoderError::AlphaPlaneSize on mismatch.

Fixes image-rs#3084

@197g 197g left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, LGTM (no regression test is okay to me here).

@197g
197g merged commit 2397f31 into image-rs:main Aug 5, 2026
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AVIF alpha-plane compositing has no dimension-equality check before zip — mismatch silently corrupts alpha instead of erroring

2 participants