Zephyr RTOS CVE-2026-10681

Three Kconfig build-time flags must all be active: CONFIG_USERSPACE=y (enables user-mode thread isolation and the __syscall k_object_alloc entry point), CONFIG_DYNAMIC_OBJECTS=y (enables runtime object allocation from which the vulnerable thread_idx_alloc() is called), and CONFIG_SMP=y (enables multi-core scheduling, which is the prerequisite for the concurrent RMW race). Single-core builds with CONFIG_SMP=n are not vulnerable regardless of other settings. The attacker must have the ability to execute user-mode threads on the target device - at minimum low-privilege local code execution (consistent with CVSS PR:L). No network-facing entry path exists; this is strictly an intra-device, user-space-to-kernel-ACL race. The race window is narrow (AC:H), requiring two threads to enter thread_idx_alloc() with sufficient concurrency to observe the same free bitmap bit before either clears it.

The CVSS 7.0 vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H accurately characterizes the exploitation barrier: the attacker must already hold user-mode thread execution on the device (PR:L, AV:L), and the race window is narrow enough to require precise concurrent scheduling on an SMP core (AC:H). Despite SSVC rating Technical Impact as total - reflecting that a successful race breaks all userspace ACL enforcement - SSVC simultaneously marks Exploitation: none and Automatable: no, consistent with the 0.08% EPSS score at the 0th percentile. These signals together indicate a serious architectural flaw whose real-world exploitation probability is currently very low: it requires local code execution already, a non-default SMP+USERSPACE+DYNAMIC_OBJECTS build configuration, and precise timing. The gap between high technical impact and near-zero exploitation signals that this is a design-priority hardening fix rather than an active incident-response item for most operators. No conflicting signals were identified; CVSS vector and description are fully consistent.

An attacker with user-mode thread execution on a Zephyr SMP device spawns two threads that simultaneously invoke k_object_alloc(K_OBJ_THREAD), racing the unlocked thread_idx_alloc() bitmap so both receive the same tidx. Once aliased, any subsequent k_object_access_grant() call on a kernel resource (such as a network socket, semaphore, or pipe) targeting the first thread automatically grants identical access to the aliasing thread, allowing the second thread to interact with kernel objects it was never explicitly authorized to access. No public proof-of-concept code is known at time of analysis.