Inconsistent behavior on overflow in hex string jump

[vthib]

Describe the bug

Integers in jumps in hex strings are unbounded, and have a behavior that is dependent on the OS when overflowing. This is because atoi is used to parse the value, and its behavior on overflow is unspecified and platform dependent. In particular, it will return INT32_MAX when overflowing on MSVC, but may return a negative number on glibc (where it is simply (int) strtol(...) afaict).

To Reproduce

See this rule:

rule hex_range {
    strings:
        $ = { 61 [0-2147483648] 62 }
    condition:
        any of them
}

On linux (glibc), it fails to compile:

error: rule "hex_range" in toto.yara(4): invalid hex string "$": invalid negative jump length

On windows (msvc), it compiles, and matches on ab.

Expected behavior

I expected either an upper bound on those values, as is done for regexes (where the upper bound is INT16_MAX), or a consistent behavior: always overflow to INT32_MAX, or always return an error when overflowing, ...

• YARA version: 4.2.3

Additional context

IMHO adding the same upper bound than regexes repetitions would be the most sensible, but it is technically a breaking change.