Skip to content

Bug: Missing NULL check for cJSON_malloc in FindPointerFromObjectTo leads to crash under OOM / allocation failure #1049

Description

@timeflies123

Issue Description:

A memory allocation vulnerability was identified in cJSON_Utils.c. In the internal logic used by cJSONUtils_FindPointerFromObjectTo, a buffer allocated via cJSON_malloc (or hooks.allocate) is passed directly into sprintf (or similar string formatting functions) without validating if the allocation was successful.

Under memory pressure or custom hook limits where malloc returns NULL, this omission causes a Null Pointer Dereference (Segmentation Fault), compromising the stability of applications relying on cJSON_Utils.

Vulnerability Analysis:

The vulnerability resides in the internal recursive helper functions of cJSON_Utils.c responsible for path resolution (such as FindPointerFromObjectTo traversing array/object elements):

// Static/Internal logic inside cJSON_Utils.c
...
full_pointer = (char*)cJSON_malloc(strlen(pointer) + length + 1);
// Vulnerability: Missing check for full_pointer == NULL
sprintf(full_pointer, "%s/%s", pointer, ...); 
...

Root Cause:

Dynamic Path Assembly: When cJSONUtils_FindPointerFromObjectTo recursively constructs the JSON Pointer path for deeply nested objects or arrays, it dynamically allocates a new string buffer (full_pointer) using cJSON_malloc.

Missing Boundary Check: The code blindly assumes that cJSON_malloc will always succeed. If the system runs out of memory, or if a custom cJSON_Hooks allocator purposefully returns NULL, full_pointer remains NULL.

Crash via sprintf: Passing a NULL destination pointer into sprintf causes an immediate write segmentation fault (SIGSEGV).

Steps to Reproduce:

Proof of Concept (PoC)

The following code simulates an Out-Of-Memory (OOM) or restricted allocation condition by utilizing cJSON_InitHooks to intercept and deliberately fail the specific allocation sequence inside cJSONUtils_FindPointerFromObjectTo:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "cJSON.h"
#include "cJSON_Utils.h"

static int g_alloc_count = 0;
static int g_fail_at = 3; // Target allocation sequence used for full_pointer

static void* tracking_malloc(size_t sz)
{
    int idx = g_alloc_count++;
    if (idx == g_fail_at) {
        fprintf(stderr, "  [HOOK] blocking malloc #%d (size=%zu) -> NULL\n", idx, sz);
        return NULL; // Simulate allocation failure
    }
    return malloc(sz);
}

int main(void)
{
    printf("[PoC] Unchecked cJSON_malloc return value in FindPointer\n");

    /* Inject custom malloc hook */
    cJSON_Hooks hooks = { tracking_malloc, free };
    cJSON_InitHooks(&hooks);

    /* Construct nested structure: [ [ 42 ] ] */
    cJSON *root = cJSON_CreateArray();
    cJSON *inner = cJSON_CreateArray();
    cJSON_AddItemToArray(root, inner);
    cJSON *target = cJSON_CreateNumber(42);
    cJSON_AddItemToArray(inner, target);

    printf("[*] Calling cJSONUtils_FindPointerFromObjectTo()...\n");

    /* Triggering vulnerability */
    char *ptr = cJSONUtils_FindPointerFromObjectTo(root, target);

    if (ptr != NULL) {
        free(ptr);
    }

    cJSON_Delete(root);
    cJSON_InitHooks(NULL); 
    return 0;
}

Expected Result:

If compiled normally, when the execution hits malloc #3, the hook returns NULL. cJSON_Utils will immediately crash with a Segmentation Fault inside sprintf due to writing to a zero page address.

(Note: Depending on the specific version and compiler optimizations, the precise allocation index g_fail_at may vary between 3 or 4 to hit the exact target buffer. A crash reliably occurs once the exact path allocation is targeted).

Suggested Fix

Add proper error handling after every cJSON_malloc call within cJSON_Utils.c. If an allocation fails, the function should gracefully abort the recursion and bubble up an error (e.g., return NULL):

full_pointer = (char*)cJSON_malloc(strlen(pointer) + length + 1);
if (full_pointer == NULL)
{
    // Clean up if necessary and return error status
    return NULL; 
}
sprintf(full_pointer, "%s/%s", pointer, ...);

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions