TL;DR: The UpdateHub OTA subsystem in Zephyr RTOS uses a single file-scope context structure for all update operations without any locking. Two concurrent code paths can race through prepare_fds(), writing past a one-element poll array and corrupting the shared context. The result is denial of service of the firmware-update path on embedded devices running Zephyr. Fixed by adding a mutex and a bounds check.

What happened

Zephyr RTOS is an open-source real-time operating system maintained by the Linux Foundation, used in industrial IoT devices, wearables, and embedded sensors across automotive, healthcare, and smart-home markets. The UpdateHub subsystem (subsys/mgmt/updatehub/updatehub.c) handles over-the-air firmware updates via CoAP.

The bug sits in how UpdateHub shares state. Every update operation flows through a single file-scope structure called ctx, which holds the CoAP block context, payload buffer, status code, socket descriptor, and a one-element poll-fd array fds[1]. Nothing serializes access to ctx. The function prepare_fds() writes to ctx.fds[ctx.nfds] then increments ctx.nfds with no bounds check.

Two independent code paths mutate ctx at the same time. The background autohandler() runs on the system workqueue and polls for updates on a schedule. User-triggered operations arrive through the updatehub run shell command, direct API calls, or (with CONFIG_USERSPACE enabled) unprivileged userspace threads. When a second flow enters prepare_fds() while ctx.nfds is already 1, the write lands one element past the end of the array. By struct layout, that overlaps the adjacent ctx.sock and ctx.nfds members.

The broader problem is the unsynchronized sharing itself. Two flows can interleave connection setup and teardown, double-closing a socket descriptor or scribbling over shared buffers. The corruption stays within the ctx structure. There is no demonstrated path to memory outside it or to code execution.

Who is affected

Zephyr RTOS builds that include the UpdateHub subsystem. The vulnerability is classified as CWE-362 (Race Condition). No CVSS score has been assigned yet by NVD at time of writing.

The trigger conditions require a local actor who can invoke update operations. With CONFIG_USERSPACE enabled, an unprivileged userspace thread can trigger the race. Remote peers cannot control the timing.

What to do

The fix adds a mutex to serialize entry points and a bounds check to prepare_fds(). The commit is 551d3f92b36e9604f039101c4e4f623682d02159 on the Zephyr mainline.

If you ship Zephyr-based devices with UpdateHub enabled:

• Pull the fix commit into your downstream Zephyr tree
• Rebuild and reflash affected devices
• Disable CONFIG_UPDATEHUB if OTA updates are not needed
• Restrict access to the updatehub shell command and update syscalls on production firmware

Why it matters

Embedded devices in the field depend on OTA update infrastructure to stay patched. When the update subsystem itself can be corrupted by a timing race, the device loses its ability to receive security fixes without physical intervention. In industrial IoT deployments, that means truck rolls and downtime. The fact that an unprivileged userspace thread can trigger the race makes this reachable on any Zephyr config with CONFIG_USERSPACE and UpdateHub both enabled.

References

• NVD: CVE-2026-11812
• GitHub Security Advisory GHSA-vprh-rff6-46xp
• Fix commit: 551d3f92b36e9604f039101c4e4f623682d02159