Summary

On 32bit system, jvp_string_append has a chance of integer/multiple overflowing and then causing a massive buffer overrun.

Details

In src/jv.c, the function jvp_string_append adds a check to ensure that the combined length of the existing string and the new data does not exceed INT_MAX:

However, if this check passes (e.g., currlen + len is just below INT_MAX), the code proceeds to double the allocation size:

this is a 32bit calculation on 32bit systems.

On a 32-bit system where INT_MAX is 2,147,483,647, a value of currlen + len such as 2,147,483,646 will pass the check. The resulting allocsz will be 4,294,967,292 (which fits in uint32_t). When this is passed to jvp_string_alloc:

static jvp_string* jvp_string_alloc(uint32_t size) {
  jvp_string* s = jv_mem_alloc(sizeof(jvp_string) + size + 1);

The expression sizeof(jvp_string) + size + 1 (where sizeof(jvp_string) is 16) will be 16 + 4,294,967,292 + 1 = 4,294,967,309. On a 32-bit system, this overflows size_t and results in an allocation of only 13 bytes. Subsequent memcpy operations in jvp_string_append will then cause a massive heap buffer overflow.

PoC

None developed