Out-of-bounds memory read in 192 branch when N=24 #24
Conversation
This file contains 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
…y 8 bytes, by using the parameter N, we can correctly determine the length to copy from the public key value.
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.
When a keypair is generated with N=24 (e.g. LMS_SHA256_N24_H15/LMOTS_SHA256_N24_W4), the public key generated is of size
4 + (8 + 16 + 24) = 52bytes.When the function
hss_validate_signature_init()begins, it moves the signature pointer up 4 bytes then attempts a memcpy which copies8 + 16 + 32 = 56bytes, the signature is currently pointing to52 - 4 = 48bytes of memory. This causes an out-of-bounds memory read of56 - 48 = 8bytes.The 8 extra bytes that are read aren't actually used for anything (as far as I'm able to tell), so I don't think it would cause any functional issues to exist, but it is an out-of-bounds memory access which shouldn't occur.
This PR resolves this by using the actual value of
nwhich was computed from thelm_ots_look_up_parameter_set()call to determine the size of data to copy withmemcpy().