The RE_OPCODE_REPEAT_END handler in _yr_re_fiber_sync does `fiber->stack[fiber->sp]++` without checking that sp is not negative:
- sp starts at -1 and only a preceding REPEAT_START advances it to 0
- a hand-crafted .yrc can reach REPEAT_END with no matching REPEAT_START, so `stack[-1]++` writes into the fiber's `next` pointer and the later fiber traversal follows the corrupted value
- the REPEAT_START push already carries the paranoid upper-bound guard, only this lower bound was missing
Added the sp < 0 guard under YR_PARANOID_EXEC. A regexp of a single REPEAT_END opcode gives an ASAN SEGV in _yr_re_fiber_split before the patch and a clean ERROR_INTERNAL_FATAL_ERROR after; regression test added in test-re-split.c.
Unbounded push onto the per-fiber repeat stack in _yr_re_fiber_sync:
- REPEAT_START does stack[++sp] = 0 with sp never checked against RE_MAX_STACK
- a crafted rule with a run of more than RE_MAX_STACK REPEAT_START opcodes writes past the 1024-entry stack at the tail of the heap RE_FIBER
- confirmed under ASAN: heap-buffer-overflow write at re.c:1560 reached through yr_re_exec
Guarded under YR_PARANOID_EXEC like the split id check above, with a regression test.
With this change the yr_scanner_scan_mem_blocks function can return ERROR_BLOCK_NOT_READY when the YR_MEMORY_BLOCK_ITERATOR that provides memory blocks to the function is not ready to return the next block. After this error the caller can retry the call to yr_scanner_scan_mem_blocks multiple times until the function succeeds or fails with some other error code.
Co-authored-by: Simon Hardy-Francis <[email protected]>
* Add test case.
* Fix issue with regexps and hex strings that were not splitted correctly.
The function yr_re_ast_split_at_chaining_point was not splitting correctly regexps and hex strings that contained more than one large jump (a.k.a gap). For example, { 01 02 03 [0-1000] 04 05 06 [500-2000] 07 08 09 } was not splitted in three parts as expected, but only in two parts: { 01 02 03 } and { 04 05 06 [500-2000] 07 08 09 } . This didn't affected the correctness of the matches, but it caused ERROR_TOO_MANY_RE_FIBERS in some cases while trying to match { 04 05 06 [500-2000] 07 08 09 } because of the large jump in the pattern. The occurrence of the error depended on the data being scanned.
This commit fixes the aforementioned issue, improves the documentation of related functions and simplifies some portions of the code.
* Avoid putting the same string multiple times in matching_strings_arena.
This fixes a small issue introduced in #1096. The same string could be put more than once in the matching_strings_arena, this doesn't causes any major error nor affect the correctness of the matching, but it could have a negative impact on performance.
* Add more comments.
* Improve documentation for _yr_scan_verify_chained_string_match.
jmestwa-coder