Albert Gierlach

An issue exists where the incremental buffer length is corrupted by chopping past its end in the `incr skip()` function after a top-level number. The incremental parser treats sequences of digits, signs, dots, and exponent markers as a single number, while the decoder stops at the end of a valid number, leaving an offset of undecoded bytes. When the buffer is emptied without clearing these bytes, a subsequent `incr parse()` call without new input reads them again and moves the offset beyond the buffer end. Consequently, `incr skip()` removes those bytes, causing the buffer length to wrap. An attacker sending input like "1-2" to an `incr parse` consumer can trigger a process exit via an uncatchable out-of-memory path in Perl.

An issue exists in the `incr parse()` function where a one-byte heap out-of-bounds write occurs when appending a one-byte chunk. This happens because the incremental buffer grows to one and a half times the required length without reserving space for the terminating NUL character. In cases involving an empty buffer and a one-byte chunk, the NUL character is written one byte past the allocation if no reallocation occurs. A peer streaming data to an `incr parse` consumer can trigger this by controlling how input is split into reads.

JSON::XS versions from 3.0 before 4.05 for Perl read freed stack memory when a FREEZE result's serialisation grows the Perl stack under allow tags in encode rv. With allow tags, an object's FREEZE method is called in list context and each returned value is encoded through a saved Perl stack pointer. When encoding a returned value calls back into Perl, through TO JSON under convert blessed or another FREEZE, and that callback grows the stack, the stack is reallocated while the saved pointer still refers to the freed block. Encoding such objects reads freed memory, and encode can return undef without an error.