133 lines
7.4 KiB
JSON
133 lines
7.4 KiB
JSON
{
|
||
"dataType": "CVE_RECORD",
|
||
"dataVersion": "5.2",
|
||
"cveMetadata": {
|
||
"cveId": "CVE-2026-76787",
|
||
"assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
|
||
"state": "PUBLISHED",
|
||
"assignerShortName": "zephyr",
|
||
"dateReserved": "2026-08-19T17:53:24.899Z",
|
||
"datePublished": "2026-10-19T20:39:20.425Z",
|
||
"dateUpdated": "2026-11-04T05:01:11.074Z"
|
||
},
|
||
"containers": {
|
||
"cna": {
|
||
"providerMetadata": {
|
||
"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad",
|
||
"shortName": "zephyr",
|
||
"dateUpdated": "2026-11-04T05:01:11.074Z"
|
||
},
|
||
"title": "NULL pointer dereference in the UpdateHub FOTA client when probe metadata omits sha256sum",
|
||
"descriptions": [
|
||
{
|
||
"lang": "en",
|
||
"value": "The UpdateHub firmware-over-the-air client parses the CoAP probe response with Zephyr's JSON library in z_impl_updatehub_probe() (subsys/mgmt/updatehub/updatehub.c). The decoder treats every descriptor field as optional — json_obj_parse() 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 resp_probe_any_boards / struct resp_probe_some_boards at NULL. Both metadata branches then computed sha256size = strlen(...objects.sha256sum) + 1 before any validation, dereferencing that NULL pointer; the SHA256_HEX_DIGEST_SIZE test that follows operates on a value the bad read has already produced and cannot prevent it.\n\nThe metadata is supplied entirely by the network peer: probe_cb() accepts the datagram, runs coap_packet_parse() and copies the payload with no token matching and no cryptographic check. With CONFIG_UPDATEHUB_DTLS unset — the default — start_coap_client() 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 updatehub_autohandler() polls on CONFIG_UPDATEHUB_POLL_INTERVAL. When CONFIG_UPDATEHUB_DTLS=y the trigger narrows to a malicious or compromised update server.\n\nThe 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 CONFIG_NULL_POINTER_EXCEPTION_DETECTION_DWT/_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.\n\nThe fix adds an explicit sha256sum == NULL test that returns UPDATEHUB_METADATA_ERROR ahead of the strlen() in both metadata branches. Debug builds (CONFIG_UPDATEHUB_LOG_LEVEL=4) still format the same pointers with %s in a LOG_DBG() loop that runs before the new checks, so that variant remains in debug configurations only."
|
||
}
|
||
],
|
||
"affected": [
|
||
{
|
||
"vendor": "zephyrproject",
|
||
"product": "zephyr",
|
||
"collectionURL": "https://github.com/zephyrproject-rtos/zephyr",
|
||
"packageName": "zephyr",
|
||
"defaultStatus": "unaffected",
|
||
"programFiles": [
|
||
"subsys/mgmt/updatehub/updatehub.c"
|
||
],
|
||
"programRoutines": [
|
||
{
|
||
"name": "z_impl_updatehub_probe"
|
||
}
|
||
],
|
||
"versions": [
|
||
{
|
||
"version": "2.4.0",
|
||
"status": "affected",
|
||
"versionType": "semver",
|
||
"lessThan": "4.3.2"
|
||
},
|
||
{
|
||
"version": "4.4.0",
|
||
"status": "affected",
|
||
"versionType": "semver",
|
||
"lessThan": "4.5.0"
|
||
}
|
||
]
|
||
}
|
||
],
|
||
"references": [
|
||
{
|
||
"url": "https://github.com/zephyrproject-rtos/zephyr/commit/6fc4f27a74021b52c509e4f7912d68145dfa7728",
|
||
"name": "Fix commit",
|
||
"tags": [
|
||
"patch"
|
||
]
|
||
},
|
||
{
|
||
"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-82gq-cmqw-xgx2",
|
||
"name": "GHSA-82gq-cmqw-xgx2"
|
||
}
|
||
],
|
||
"metrics": [
|
||
{
|
||
"format": "CVSS",
|
||
"cvssV3_1": {
|
||
"version": "3.1",
|
||
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
|
||
"baseScore": 5.9,
|
||
"baseSeverity": "MEDIUM"
|
||
}
|
||
}
|
||
],
|
||
"problemTypes": [
|
||
{
|
||
"descriptions": [
|
||
{
|
||
"lang": "en",
|
||
"description": "memory-safety",
|
||
"cweId": "CWE-476",
|
||
"type": "CWE"
|
||
}
|
||
]
|
||
}
|
||
],
|
||
"x_generator": {
|
||
"engine": "cvelib 1.8.0"
|
||
}
|
||
},
|
||
"adp": [
|
||
{
|
||
"metrics": [
|
||
{
|
||
"other": {
|
||
"type": "ssvc",
|
||
"content": {
|
||
"id": "CVE-2026-76787",
|
||
"role": "CISA Coordinator",
|
||
"options": [
|
||
{
|
||
"Exploitation": "none"
|
||
},
|
||
{
|
||
"Automatable": "no"
|
||
},
|
||
{
|
||
"Technical Impact": "partial"
|
||
}
|
||
],
|
||
"version": "2.0.3",
|
||
"timestamp": "2026-10-20T18:04:36.017568Z"
|
||
}
|
||
}
|
||
}
|
||
],
|
||
"title": "CISA ADP Vulnrichment",
|
||
"providerMetadata": {
|
||
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
|
||
"shortName": "CISA-ADP",
|
||
"dateUpdated": "2026-10-20T18:08:01.790Z"
|
||
}
|
||
}
|
||
]
|
||
}
|
||
} |