I found a UAF caused by sort_list() in cJSON_Utils.c.It rebuilds an object's doubly linked list with mergesort but never restores cJSON's invariant child->prev == tail. After a sort, head->prev is either NULL or a live interior node. If that interior node is later removed (freed) and a member is then added to the same object, add_item_to_array() runs suffix_object(child->prev, item) → prev->next = item , writing 8-byte write into freed heap memory.
Branch : master 6d9f2443ab071f86e5d9b43025a40929ec41c46c.
Root cause
sort_list() (cJSON_Utils.c:484), merge loop:
if (result == NULL)
{
/* start merged list with the smaller element */
result_tail = smaller;
result = smaller; /* smaller->prev keeps its pre-sort value */
}
Only ->next and the prev of subsequently appended elements are maintained. The split path explicitly sets second->prev = NULL (cJSON_Utils.c:~528), so the stale value on the merged head is either NULL or a node that is still in the list.
cJSON depends on child->prev == tail. Established by the parser: head->prev = current_item (cJSON.c:1761) and consumed by add_item_to_array(): suffix_object(child->prev, item) (cJSON.c:2052) → prev->next = item (cJSON.c:2001).But the detach path only repairs it when the tail is removed (cJSON.c:2284), so deleting an interior node leaves child->prev dangling.
Reproduction (attached: poc_min.c)
three public API calls
gcc -g -O1 -fsanitize=address -I. cJSON.c cJSON_Utils.c poc_min.c -o poc_min -lm
./poc_min
POC
poc_min.c
asan-log.txt
I found a UAF caused by sort_list() in cJSON_Utils.c.It rebuilds an object's doubly linked list with mergesort but never restores cJSON's invariant child->prev == tail. After a sort, head->prev is either NULL or a live interior node. If that interior node is later removed (freed) and a member is then added to the same object, add_item_to_array() runs suffix_object(child->prev, item) → prev->next = item , writing 8-byte write into freed heap memory.
Branch : master
6d9f2443ab071f86e5d9b43025a40929ec41c46c.Root cause
sort_list()(cJSON_Utils.c:484), merge loop:Only
->nextand theprevof subsequently appended elements are maintained. The split path explicitly setssecond->prev = NULL(cJSON_Utils.c:~528), so the stale value on the merged head is eitherNULLor a node that is still in the list.cJSON depends on
child->prev == tail. Established by the parser:head->prev = current_item(cJSON.c:1761) and consumed byadd_item_to_array():suffix_object(child->prev, item)(cJSON.c:2052) →prev->next = item(cJSON.c:2001).But the detach path only repairs it when the tail is removed (cJSON.c:2284), so deleting an interior node leaveschild->prevdangling.Reproduction (attached:
poc_min.c)three public API calls
POC
poc_min.c
asan-log.txt