GHSA-w234-pcxp-4q8r: NULL-pointer dereference in Zephyr OCPP CALLRESULT parsing via unchecked strtok_r/atoi

The OCPP 1.6 client in subsys/net/lib/ocpp/ocpp.c reconstructs a session handle and PDU id from the uid field of a CALLRESULT message. In ocppprocessservermsg() the code calls atoi(strtokr(uid, "-", &tmp)) without checking the strtokr return value. When the server-supplied uid is empty or contains no - delimiter, strtokr() returns NULL and atoi(NULL) dereferences a NULL pointer, which is undefined behaviour.

The uid originates from network data: parserpcmsg() in subsys/net/lib/ocpp/ocppj.c JSON-parses a frame received from the OCPP central system over TCP/WebSocket and copies the server-controlled string into the local buffer. A malicious or compromised central system, or a man-in-the-middle on a non-TLS ws:// connection, can return a malformed uid to reach the defect. No authentication beyond the existing server connection (or MITM position) is required, and the reconstructed pointer is membership-validated by ocppsessionisvalid(), so the impact is limited to the NULL dereference rather than arbitrary pointer use.

On Zephyr targets that trap access to address 0 (MMU/MPU platforms or CONFIGNULLPOINTEREXCEPTIONDETECTION), the dereference faults inside the OCPP reader thread and invokes the fatal handler, producing a remote denial of service of the charge point; on bare targets where address 0 is readable the call returns 0 and is benign, so the impact is availability-only and platform-conditional.

The applied fix guards only the first atoi(); the second strtokr(NULL, "-", &tmp) followed by pdu = atoi(buf) in the same function remains unguarded and the identical NULL dereference is still reachable from the same network input when the uid has a first token but no second --delimited token. A complete fix should validate the second token as well.