Check for the subject end before the first start-bits load - #985
Conversation
fast_forward_start_bits_simd() checked STR_PTR against STR_END before its first load only when the offset was nonzero. mainloop_entry() can advance STR_PTR to STR_END before calling it, and if STR_END is on a page boundary the aligned load then reads the next page, which faults when that page is unmapped.
fast_forward_start_bits_simd() checked STR_PTR against STR_END before its first load only when the offset was nonzero. mainloop_entry() can advance STR_PTR to STR_END before calling it, and if STR_END is on a page boundary the aligned load then reads the next page, which faults when that page is unmapped. Fixes PCRE2Project#984
|
Great! Unconditional checks are safe, and it's fixed in both sites. I'm very disturbed by the fact that the OpenBSD build is the only one that caught this. We test with valgrind in our CI, which has pretty similar checks for overreads. But nothing failed in CI. That seems to be because the entire JIT SIMD code is removed when SUPPORT_VALGRIND is defined: and our CI makes sure to turn on the Valgrind build-time support when we run the tests under Valgrind! @zherczeg - Surely we should fix that, right? This issue is caught immediately on Linux when we run Nor should we test that configuration! Shouldn't we just remove |
3 participants
The Alpha and x86-64 start-bits scans checked STR_PTR against STR_END before
their first load only when the offset was nonzero. mainloop_entry() can
advance STR_PTR to STR_END before calling the scan, and if STR_END is on a
page boundary the aligned load then reads the next page. Check the end of the
subject unconditionally.
Tested on Alpha under qemu-alpha with the subject placed right before an
unmapped page: patterns such as
[a-c](?=\d)againstzzzzzzzafaultwithout the fix and return no match with it.
pcre2_jit_testandRunTestpass on Alpha, and ctest passes on x86-64.
Fixes #984