CVE-2026-76787: NULL pointer dereference in the UpdateHub FOTA client when probe metadata omits sha256sum
The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in zimplupdatehubprobe() (subsys/mgmt/updatehub/updatehub.c). The decoder treats every descriptor field as optional — jsonobjparse() returns a bitmask of the fields it actually decoded and never fails on a missing one — so a response that omits the "sha256sum" string leaves the corresponding const char in the zero-initialised struct respprobeanyboards / struct respprobesomeboards at NULL. Both metadata branches then computed sha256size = strlen(...objects.sha256sum) + 1 before any validation, dereferencing that NULL pointer; the SHA256HEXDIGESTSIZE test that follows operates on a value the bad read has already produced and cannot prevent it.
The metadata is supplied entirely by the network peer: probecb() accepts the datagram, runs coappacketparse() and copies the payload with no token matching and no cryptographic check. With CONFIGUPDATEHUBDTLS unset — the default — startcoapclient() uses plain CoAP over UDP on port 5683 with no peer authentication and resolves the server via unauthenticated DNS, so an on-path attacker, a DNS spoofer, or an off-path attacker who wins the race with a forged source address can deliver the malformed metadata. A probe response as simple as "objects":[[{}],[{}]] suffices, and no user interaction is required because updatehubautohandler() polls on CONFIGUPDATEHUBPOLLINTERVAL. When CONFIGUPDATEHUBDTLS=y the trigger narrows to a malicious or compromised update server.
The primitive is a read at address zero, not a write, so the impact is availability only. On targets where the low address range is unmapped or protected — MMU-based architectures, builds with CONFIGNULLPOINTEREXCEPTIONDETECTIONDWT/MPU/PMP, TrustZone non-secure images, and SoCs such as nRF54L whose 0x0–0x400 window is unmapped — the load faults and Zephyr's default fatal handler halts the system, giving a remotely re-triggerable denial of service on every poll. On classic Cortex-M targets where the vector table is readable at address zero the walk usually terminates immediately and the request is rejected by the length check, so the outcome is configuration- and SoC-dependent. There is no memory write, and the copied bytes are only compared against the locally computed image hash, so there is no information-disclosure channel.
The fix adds an explicit sha256sum == NULL test that returns UPDATEHUBMETADATAERROR ahead of the strlen() in both metadata branches. Debug builds (CONFIGUPDATEHUBLOGLEVEL=4) still format the same pointers with %s in a LOGDBG() loop that runs before the new checks, so that variant remains in debug configurations only.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Enable DTLS for UpdateHub so the trigger is limited to a malicious or compromised update server instead of unauthenticated plain CoAP over UDP.
UpdateHub FOTA client CONFIG_UPDATEHUB_DTLS = y
Event History
Frequently Asked Questions
Which deployments are exposed by default?
UpdateHub clients with CONFIG_UPDATEHUB_DTLS unset are exposed by default. In that configuration, the client uses unauthenticated CoAP over UDP port 5683 and resolves its server through unauthenticated DNS.
What must an attacker be able to do to trigger the failure?
An attacker must cause the client to accept a probe response whose metadata omits the sha256sum field. The probe path does not match tokens or cryptographically verify the payload, so an on-path attacker or DNS spoofer can supply such a response; the description also identifies off-path attackers as a concern.
What is the practical impact of a malformed probe response?
The client dereferences a NULL sha256sum pointer while calculating its length, before later SHA256 length validation occurs. This can crash the affected UpdateHub client and cause a denial of service.