Conversation
jpc_dec_tileinit() computes rlvl->numprcs = numhprcs * numvprcs in unsigned 32 bits and only then applies the 64*1024 sanity limit, so a crafted codestream whose true product exceeds 2^32 wraps to a small value, passes the check, and leaves band->prcs/prclyrnos severely under-allocated. Later packet iteration then reads and writes out of bounds (see issue jasper-software#423 for an ASan report). Evaluate the product in uint_fast64_t and apply the limit to the true value before assigning numprcs. The wrapped-numprcs debug print and the now-redundant post-assignment check are folded into the new pre-assignment check. Part of jasper-software#423 (bug 1).
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Part of #423 (bug 1) —
jpc_dec_tileinit()computesin unsigned 32 bits and only then applies the
64 * 1024sanity limit. A crafted codestream whose true product exceeds 2^32 wraps to a small value, passes the check, and leavesband->prcs/prclyrnosseverely under-allocated — subsequent packet iteration then reads/writes out of bounds (the issue's ASan report shows the crash in RPCL iteration).Fix
Evaluate the product in
uint_fast64_tand apply the existing64 * 1024limit to the true value before assigningnumprcs. The post-assignment check is folded into the new pre-assignment check; the debug print still reports the final (bounded)numprcs.Notes on the other bugs in #423
Bugs 2 (
asclen == 0) and 4 (cnt == 0) are already fixed on master (asclen < 1/cnt < 1checks injas_icc.c), and the vulnerable code path for bug 3 is inside#if 0injp2_dec.c. This PR covers the one remaining live issue.