setting heap_limit could be truncated since PCRE2 10.41 #183
Comments
carenas
changed the title
carenas
added a commit
to carenas/pcre2
that referenced
this issue
Jan 1, 2023
If a LIMIT_HEAP value once converted to bytes is larger than UINT_MAX
would result in a bogus setting that could trigger a matching failure
as shown by the following:
PCRE2 version 10.42 2022-12-11
re> /(*LIMIT_HEAP=4194304)a/
data> a
Failed: error -63: heap limit exceeded
Remove the multiplication and instead keep track of the maximum heap
allowed in KB as was done originally.
Aditionally, add a check to avoid overflowing a PCRE2_SIZE while
doubling the heap used and that could result in a crash (mostly on
systems with a 32-bit PCRE2_SIZE with non standard settings).
Fixes: d90fb23 (Refactor match_data() to always use the heap instead
of having an initial frames vector on the stack..., 2022-07-27)
Closes: PCRE2Project#183
carenas
added a commit
to carenas/pcre2
that referenced
this issue
Jan 10, 2023
If a LIMIT_HEAP value once converted to bytes is larger than UINT_MAX
would result in a bogus valueg that could trigger a matching failure
as shown by the following:
PCRE2 version 10.42 2022-12-11
re> /(*LIMIT_HEAP=4194304)a/
data> a
Failed: error -63: heap limit exceeded
Remove the multiplication and instead keep track of the maximum heap
allowed in KB as was done originally.
Aditionally, add a check to avoid overflowing a PCRE2_SIZE while
doubling the heap used and that could result in a crash (only on
systems with a 32-bit PCRE2_SIZE and using non standard settings).
Unlike the original, this code avoids rounding the heapframes_size
to the frame_size at the allocation time, which simplifies the logic
and wasn't really needed.
Fixes: d90fb23 (Refactor match_data() to always use the heap instead
of having an initial frames vector on the stack..., 2022-07-27)
Closes: PCRE2Project#183
carenas
added a commit
to carenas/pcre2
that referenced
this issue
Jan 14, 2023
If a LIMIT_HEAP value once converted to bytes is larger than UINT_MAX
would result in a bogus setting that could trigger a matching failure
as shown by the following:
PCRE2 version 10.42 2022-12-11
re> /(*LIMIT_HEAP=4194304)a/
data> a
Failed: error -63: heap limit exceeded
Remove the multiplication and instead keep track of the maximum heap
allowed in KB as was done originally.
Aditionally, add a check to avoid overflowing a PCRE2_SIZE while
doubling the heap used and that could result in a crash (only on
systems with a 32-bit PCRE2_SIZE and using non standard settings).
Unlike the original, this code avoids rounding the heapframes_size
to the frame_size at the allocation time, which simplifies the logic
and wasn't really needed.
Fixes: d90fb23 (Refactor match_data() to always use the heap instead
of having an initial frames vector on the stack..., 2022-07-27)
Closes: PCRE2Project#183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After d90fb23 (Refactor match_data() to always use the heap instead of having an initial frames vector on the stack..., 2022-07-27) the value for
mb->heap_limit(using a PCRE2_SIZE) is set to the number of bytes, instead of KB (as used everywhere else).The problem with doing that is that the variable that holds this in the match/expression context is only 32bit wide and therefore setting the value itself requires multiplying that value by 1024 and that can overflow.
Changing the code to widen the multiplication itself helps when PCRE2_SIZE is 64bit but it won't in 32bit systems where PCRE2_SIZE isn't just wide enough:
Additionally, since the default for heap_limit is set to 20000000KB, it is already larger (when converted into bytes) than what a 32bit PCRE2_SIZE can hold, and while that specific issue was already present in previous code, meaning that the limit was practically unreachable, it was at least representable and useful for evaluation.
The text was updated successfully, but these errors were encountered: