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.