Repository navigation
[Java] Reject out-of-range var-data lengths in the skip, wrap and get accessors - #1182
Open
slachiewicz wants to merge 1 commit into
Open
slachiewicz wants to merge 1 commit into
slachiewicz wants to merge 1 commit into
Conversation
… accessors. A uint32 length of 2^31 or more cast to a negative int and moved the parent limit backwards. The check mirrors the String accessor and also rejects a length that runs past the buffer, before the limit moves.
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
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.
A var-data field with a uint32 length prefix is read as (int), so a length of 2^31 or more became negative and moved the parent limit backwards. skipX(), wrapX(), getX(MutableDirectBuffer), getX(byte[]) and getX(Appendable) now throw IndexOutOfBoundsException before the limit moves when the length is negative (uint32 prefixes only) or runs past the buffer, the same check the String accessor has in #1150.
The check is emitted for every length type, so the generated IR codecs (uint16 lengths) gain it too and are regenerated. It sits in different hunks from #1150, but both touch FrameCodecDecoder and TokenCodecDecoder, so expect a mechanical rebase of the generated files.
Part of #969.
Verified: the new VarDataUint32LengthTest fails 15 of 17 on master and passes here; sbe-tool checkstyle and test, verifyJavaIrCodecsInSync and sbe-samples:check pass.