jit: avoid wraparound in stack size #42
Merged
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
pcre2_jit_stack_create() allows the user to indicate how big of a stack size JIT should be able to allocate and use, using a size_t variable which should be able to hold bigger values than reasonable. Internally, the value is rounded to the next 8K, but if the value is unreasonable large, would overflow and could result in a smaller than expected stack or a maximun size that is smaller than the minimum.. Avoid the overflow by checking the value and failing early, and while at it make the check clearer while documenting the failure mode. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
carenas
force-pushed
the
jitstackalloc
branch
from
c80cd8a to
a80a1b0
Compare
carenas
added a commit
to carenas/pcre2
that referenced
this pull request
Jan 6, 2022
eb42305 (jit: avoid integer wraparound in stack size definition (PCRE2Project#42), 2021-11-19) introduces a check to avoid an integer overflow when allocating stack size for JIT. Unfortunately the maximum value was using PCRE2_SIZE_MAX, eventhough the variable is of type size_t, so correct it. Practically; the issue shouldn't affect the most common configurations where both values are the same, and it will be unlikely that there would be a configuration where PCRE2_SIZE_MAX > SIZE_MAX, hence the mistake is unlikely to have reintroduced the original bug and this change should be therefore mostly equivalent. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
zherczeg
pushed a commit
that referenced
this pull request
Jan 6, 2022
eb42305 (jit: avoid integer wraparound in stack size definition (#42), 2021-11-19) introduces a check to avoid an integer overflow when allocating stack size for JIT. Unfortunately the maximum value was using PCRE2_SIZE_MAX, eventhough the variable is of type size_t, so correct it. Practically; the issue shouldn't affect the most common configurations where both values are the same, and it will be unlikely that there would be a configuration where PCRE2_SIZE_MAX > SIZE_MAX, hence the mistake is unlikely to have reintroduced the original bug and this change should be therefore mostly equivalent. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
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.
An integer overflow that is slightly more relevant in the old PCRE codebase (where it will lead to Undefined Behaviour and if able to be triggered correctly a bug that might have security implications), but still worth addressing explicitly in the new codebase IMHO.
Avoid the overflow by checking and failing the value early, and
while at it make the check clearer and document the failure mode.