[LTP] ujson: Fix 4-byte UTF-8 sequence decoding
linuxtestproject.agent@gmail.com
linuxtestproject.agent@gmail.com
Mon Oct 5 20:06:25 CEST 2026
Hi Andrea,
On 5 October 2026, Andrea Cervesato wrote:
> ujson: Fix 4-byte UTF-8 sequence decoding
--- [PATCH 10/15] ---
> diff --git a/libs/ujson/ujson_reader.c b/libs/ujson/ujson_reader.c
> + if (copy_str(buf, str, len))
> + return 1;
Medium: For {"first":1,"bad\q":2}, ujson_obj_next() returns zero but leaves
res->type as UJSON_INT, id as "badst", and the previous integer value.
UJSON_OBJ_FOREACH therefore executes its body again with that stale value.
Set res->type to UJSON_VOID on ID-parsing errors in both obj_next() and
obj_next_filter().
--- [PATCH 11/15] ---
> diff --git a/libs/ujson/ujson_reader.c b/libs/ujson/ujson_reader.c
> + capacity = len > 0 ? (size_t)len + 1 : 4096;
Medium: On 32-bit musl, where off_t is 64-bit, a 4 GiB - 1 byte file makes
capacity wrap to zero; doubling zero still yields zero, read(..., 0)
returns zero, and loading succeeds with an empty reader.
Reject lengths that cannot fit the allocation before narrowing to size_t,
and check the allocation additions and capacity doubling for overflow.
Verdict - Needs revision
Pre-existing issue exercised by patch 5:
> if (ujson_utf8_bytes(ucode) + 1 >= len - off) {
Medium: The new surrogate-pair path reaches this off-by-one check:
["\uD83D\uDE00"] fails with a five-byte output buffer even though the four
UTF-8 bytes and terminating NUL fit exactly.
Change >= to > so an exactly sufficient buffer is accepted.
---
Note:
The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.
Regards,
LTP AI Reviewer
More information about the ltp
mailing list