Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[jpegli] fix buffer overflow when chroma component has refinement #15

Merged
merged 2 commits into from
Jul 29, 2024

Conversation

haixia-meta
Copy link
Contributor

@haixia-meta haixia-meta commented Jul 18, 2024

See issue 14 for context.

Under certain conditions, num_refinement_bits is computed wrongly causing a heap-buffer-overflow in jpegli's TokenizeACRefinementScan in https://github.com/google/jpegli/blob/main/lib/jpegli/entropy_coding.cc#L255

The problem seems to be function TokenizeJpeg which only has a single 1D array int num_refinement_scans[DCTSIZE2] to keep track of number of refinement passes for each DCT coefficient. This is inadequate when multiple color components have different refinement sequences.

Description

Pull Request Checklist

  • CLA Signed: Have you signed the Contributor License Agreement (individual or corporate, as appropriate)? Only contributions from signed contributors can be accepted.
  • Authors: Have you considered adding your name to the AUTHORS file?
  • Code Style: Have you ensured your code adheres to the project's coding style guidelines? You can use ./ci.sh lint for automatic code formatting.

Please review the full contributing guidelines for more details.

haixia-meta and others added 2 commits July 17, 2024 22:27
Under certain conditions, num_refinement_bits is computed wrongly causing a heap-buffer-overflow in jpegli's TokenizeACRefinementScan in https://github.com/google/jpegli/blob/main/lib/jpegli/entropy_coding.cc#L255

The problem seems to be function TokenizeJpeg which only has a single 1D array int num_refinement_scans[DCTSIZE2] to keep track of number of refinement passes for each DCT coefficient. This is inadequate when multiple color components have different refinement sequences.
The num_refinement_bits is an upper bound for the allocation required.

For luma-only refinement this equality always holds. But when chroma refinement is involved, then some scans may not use up the entire allocation.
@szabadka szabadka merged commit 403631c into google:main Jul 29, 2024
29 of 47 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.

2 participants