I rechecked current apache/mynewt-core master and this still looks like a real bug.
In encoding/json/src/json_decode.c, the string decode path copies into lptr with strncpy(lptr, valbuf, cursor->len) and then only terminates valbuf itself. That means the destination buffer is not guaranteed to end with � when the decoded JSON string reaches the caller's limit. If later code treats lptr as a normal C string, it can read past the intended end; if lptr points at a field inside a larger object, the bad termination can also become a setup for follow-on intra-object misuse.
I checked the recent issue history before writing this and did not find a matching report for this sink.
A safe fix would need to make the destination write length-aware, or otherwise guarantee termination on the target side instead of the source side.
Relevant snippet:
(void)strncpy(lptr, valbuf, cursor->len);
valbuf[sizeof(valbuf)-1] = '�';
I rechecked current apache/mynewt-core master and this still looks like a real bug.
In
encoding/json/src/json_decode.c, the string decode path copies intolptrwithstrncpy(lptr, valbuf, cursor->len)and then only terminatesvalbufitself. That means the destination buffer is not guaranteed to end with�when the decoded JSON string reaches the caller's limit. If later code treatslptras a normal C string, it can read past the intended end; iflptrpoints at a field inside a larger object, the bad termination can also become a setup for follow-on intra-object misuse.I checked the recent issue history before writing this and did not find a matching report for this sink.
A safe fix would need to make the destination write length-aware, or otherwise guarantee termination on the target side instead of the source side.
Relevant snippet: