CVE-2026-10849
HighCVSS 8.2Exploitation Probability (EPSS)
Low risk25th percentile - higher than 25% of all known CVEs
Summary
The hawkBit device management client in Zephyr RTOS has a heap-based out-of-bounds write vulnerability. The response buffer lacks space for a terminating null byte, causing a single null byte write past the allocated memory when the response length matches the buffer size.
Risk Assessment
A remote malicious update server or Man-in-the-Middle attacker can cause heap corruption, leading to denial of service (DoS) and potentially limited further data corruption.
Recommendation
Immediately update Zephyr RTOS to a version containing the fix, which sizes the buffer to body length plus one and uses memcpy for copying.
Other vulnerabilities in Zephyr RTOS
See all- CVE-2026-19940Medium
A vulnerability in the Bluetooth Classic Hands-Free Profile Audio Gateway (HFP AG) implementation in Zephyr RTOS causes corruption of the kernel timeout list. By sending AT+CIND? and quickly reconnecting, a remote attacker can trigger a system-wide fault or hang.
- CVE-2026-19575High
A vulnerability in Zephyr RTOS affects the user-mode verification handler z_vrfy_device_deinit() in kernel/device.c, which validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). Because k_object_validate() short-circuits type comparison for K_OBJ_ANY, the check only verified that the pointer was the base address of some kernel object the calling thread was granted, without comparing the object's actual type. This allows a local user-mode thread to pass a thread stack object (e.g., from k_thread_stack_alloc()) and achieve supervisor-mode kernel code execution.
- CVE-2026-19574High
In the ARM64 MMU back-end of Zephyr RTOS, address space identifiers (ASIDs) are assigned by a bare round-robin counter, which after wrapping past 255 possible values can hand the same ASID to a new domain while a still-live domain holds it. Because domain-private mappings are installed as non-global (MT_NG), the ASID is the only tag separating cached translations in the TLB, and the context-switch path does not flush the TLB for a duplicate reached through a third domain. As a result, user-mode threads in one domain can read and write memory belonging to another domain, defeating memory-domain isolation.
- CVE-2026-19569High
A vulnerability in the Zephyr RTOS kernel allows an unprivileged user-mode thread to perform an out-of-bounds write in kernel memory. It stems from missing overflow checks when calculating allocation sizes for dynamic kernel objects, leading to undersized heap allocations. An attacker can exploit this to escalate privileges and execute arbitrary code at the kernel level.
- CVE-2026-19185High
A vulnerability was found in the system-call verifier for i3c_do_ccc() in Zephyr RTOS, which fails to validate per-target data pointers in the i3c_ccc_payload structure. The verifier also operates on the caller's live structure, allowing another thread to modify fields between check and use. This allows an unprivileged thread to write to arbitrary kernel addresses (via read CCC) or disclose kernel memory (via write CCC), leading to privilege escalation.
- CVE-2026-18747Medium
A vulnerability in the SMP-over-console transport in Zephyr RTOS allows an unauthenticated attacker to trigger a buffer length underflow by sending a single 7-byte frame to the management console. This leads to an out-of-bounds read, potentially causing a denial of service on the MCUmgr thread or memory disclosure.
- CVE-2026-18417Medium
In Zephyr RTOS, a vulnerability exists in the BSD socket layer where an asynchronous error was stored in the user_data field of the network context, which for listening TCP sockets is used to store a pointer to the parent context. In v4.3.0, after an interface-down event, the accept callback was not disarmed, leading to reuse of the poisoned value as a pointer and writes to an invalid address, causing a kernel fatal error (device crash or reset).
- CVE-2026-16513High
A vulnerability in the RTIO syscall verifier in Zephyr RTOS (before v4.3.0) allows an unprivileged user thread to write a pointer to controlled data at an arbitrary kernel address. The missing K_SYSCALL_MEMORY_WRITE check for the handle output parameter enables privilege escalation to kernel mode.
- CVE-2026-16514Medium
The gptp_mi_qualify_announce() function in Zephyr's gPTP subsystem processes received Announce messages by comparing clock identities. The comparison loop uses an attacker-controlled step count (steps_removed) instead of the actual number of TLV entries, leading to an out-of-bounds read. A single frame can cause about 2KB of overread, potentially crashing the networking RX thread and causing denial of service.
- CVE-2026-16512Low
The gptp_handle_msg() function in Zephyr RTOS does not validate the received frame length before dereferencing the gPTP header pointer. A truncated frame can lead to out-of-bounds reads, disclosing stale memory contents.
Original NVD description (English source)
The hawkBit device management client in subsys/mgmt/hawkbit accumulates the body of an HTTP response from the update server into a heap buffer in response_json_cb() (subsys/mgmt/hawkbit/hawkbit.c). The buffer is sized to hold the received body bytes but reserves no space for a terminating NUL. When the full response has arrived, the code writes response_data[downloaded_size] = '\0' — and whenever the accumulated body length equals the allocation, that terminator lands one byte past the end of the heap object (a heap-based out-of-bounds write, CWE-122 / CWE-787). The body length and fragmentation are taken directly from the parsed HTTP response (rsp->body_frag_start / rsp->body_frag_len) and are fully controlled by the remote hawkBit server, which chooses its own response length. The precise trigger depends on how the buffer grows, and both forms are remotely reachable. Since v4.0.0 the reallocation is sized to exactly downloaded_size + body_len, so any response body larger than the 1100-byte initial buffer makes the out-of-bounds write deterministic; such response sizes are normal for hawkBit deployment metadata. Before v4.0.0 the buffer grew by doubling and the growth check ((downloaded_size + body_len) > response_buffer_size) is false at equality, so a response body whose length is exactly the current allocation — 1100 bytes with the default initial buffer — skips the reallocation entirely and writes the terminator at response_data[1100] of an 1100-byte object. The HTTP length-mismatch check does not catch this, because the declared and received lengths genuinely agree. Either form is reachable by a malicious, compromised, or man-in-the-middle update server (TLS is optional and, when enabled, does not protect against a hostile server), with no authentication of response content and no client-side length cap protecting the write. The out-of-bounds write is a fixed single NUL byte immediately following the allocation, corrupting adjacent allocator metadata or the next allocation. The practical impact is heap corruption leading to denial of service (fault on a subsequent allocation or free), with the bounded, allocator-dependent possibility of further corruption. The fix sizes the buffer to the body length plus one and copies with memcpy, ensuring the terminator always lands within the allocation.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS