{"id":"CVE-2026-13217","summary":"NULL-pointer dereference in Zephyr OCPP CALLRESULT parsing via unchecked strtok_r/atoi","details":"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 ocpp_process_server_msg() the code calls atoi(strtok_r(uid, \"-\", &tmp)) without checking the strtok_r return value. When the server-supplied uid is empty or contains no - delimiter, strtok_r() returns NULL and atoi(NULL) dereferences a NULL pointer, which is undefined behaviour.\n\nThe uid originates from network data: parse_rpc_msg() in subsys/net/lib/ocpp/ocpp_j.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 ocpp_session_is_valid(), so the impact is limited to the NULL dereference rather than arbitrary pointer use.\n\nOn Zephyr targets that trap access to address 0 (MMU/MPU platforms or CONFIG_NULL_POINTER_EXCEPTION_DETECTION), 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.\n\nThe applied fix guards only the first atoi(); the second strtok_r(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.","aliases":["GHSA-w234-pcxp-4q8r"],"modified":"2026-11-05T03:31:25.894405361Z","published":"2026-08-25T16:05:38.128Z","database_specific":{"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/13xxx/CVE-2026-13217.json","cna_assigner":"zephyr","cwe_ids":["CWE-476"]},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/13xxx/CVE-2026-13217.json"},{"type":"ADVISORY","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-w234-pcxp-4q8r"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-13217"},{"type":"FIX","url":"https://github.com/zephyrproject-rtos/zephyr/commit/4d8a9eb1448061ccee557ef20a2a58aec91d9cad"},{"type":"FIX","url":"https://github.com/zephyrproject-rtos/zephyr/commit/eba36f8ed63a055ed862ab2b4bb801b6dce07bb7"},{"type":"PACKAGE","url":"https://github.com/zephyrproject-rtos/zephyr"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/zephyrproject-rtos/zephyr","events":[{"introduced":"3568e1b6d5cdd51a6b964a2a1d6d29200fea2056"},{"fixed":"28af05ca658cbacf745fd5b099566311c58ccb1d"},{"introduced":"684c9e8f32e4373a21098559f748f06915f950c9"},{"fixed":"dccb09599635bdff17633fa7e9dab014b91dce90"},{"fixed":"4d8a9eb1448061ccee557ef20a2a58aec91d9cad"},{"fixed":"eba36f8ed63a055ed862ab2b4bb801b6dce07bb7"}],"database_specific":{"extracted_events":[{"source":"AFFECTED_FIELD","strategy":"StandardRange","range":[{"introduced":"4.3.0"},{"fixed":"4.3.2"}]},{"range":[{"introduced":"4.4.0"},{"fixed":"4.4.2"}],"source":"AFFECTED_FIELD","strategy":"StandardRange"},{"range":[{"fixed":"4d8a9eb1448061ccee557ef20a2a58aec91d9cad"}],"source":"REFERENCES_COMMIT"},{"source":"REFERENCES_COMMIT","range":[{"fixed":"eba36f8ed63a055ed862ab2b4bb801b6dce07bb7"}]}]}}],"versions":["v4.4.2-rc1","v4.3.1","v4.3.1-rc1","v4.4.1","v4.4.1-rc1","v4.4.0","v4.3.0"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-13217.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"}]}