The error you're describing is more likely to happen with an array of ints (or really any other type without a sentinel value).
Strings specifically are often enclosed enclosed in a `while(c != '\0')` loop (assume c is the character being examined) or something to that effect, which means you'll exit at the end of the string (non-string arrays don't have this).
The CVE in question seems to be the exact opposite of this. It's that someone didn't check the bounds on a write instead of a read.
`while(c != '\0')` is the same as `while(c != '"')`. An attacker controlled string may very will be missing the 0 byte, which has been an extremely common attack vector (though is probably not a realistic attack vector for JSON parsers, to be fair).
> An attacker controlled string may very will be missing the 0 byte
Entirely possible, especially if the attacker is local. But when we're dealing with something coming in over the network, I think even the old arpa headers get you a null byte at the end, regardless of if one was sent.
Unless we aren't dealing with tcp/ip, in which case I'm way out of my depth.
Strings specifically are often enclosed enclosed in a `while(c != '\0')` loop (assume c is the character being examined) or something to that effect, which means you'll exit at the end of the string (non-string arrays don't have this).
The CVE in question seems to be the exact opposite of this. It's that someone didn't check the bounds on a write instead of a read.