CVE-2026-10681: race in zephyrproject zephyr
Affects zephyrproject zephyrSource CVE Database V5
Not known to be exploited · CVSS 6.5 Medium.
Data as of 10/25/2026, 04:40:11 UTC
- Exploitation
Not in CISA KEV, no exploitation reported
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 1% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:LWhat to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| zephyrprojectzephyr | Affected
| Fixed in
|
GitHubzephyrpkg:github/zephyrOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
The vulnerability requires specific kernel configurations (CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, CONFIG_SMP) and can be triggered via the k_object_alloc syscall. Until an official fix is available, avoid configurations enabling these options simultaneously or restrict concurrent user-mode thread creation on SMP systems if feasible.
Description
In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock. On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx. The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool. The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and including v4.4.0. Fixed by holding lists_lock across the bitmap RMW and the permissions clear (and inlining the obj_list traversal that previously took the lock itself).
Impact
The vulnerability allows two distinct user-mode threads to share the same thread permission index, causing them to share access rights to kernel objects. This breaks userspace access control isolation, potentially allowing one thread to access resources intended only for the other. The impact includes confidentiality and integrity violations (high impact) and a low impact on availability. Exploitation requires local access and concurrent thread creation on SMP systems.
Summary
In Zephyr's userspace dynamic-objects subsystem, the function thread_idx_alloc() allocates thread permission indices from a global bitmap without holding the necessary lists_lock. On SMP systems, concurrent invocations of k_object_alloc(K_OBJ_THREAD) can cause two user-mode threads to receive the same thread permission index due to a race in clearing bits in the bitmap. This leads to two kernel thread objects sharing the same thread_id, causing their permissions to alias in kernel object permission bitfields. Consequently, granting access to one thread implicitly grants access to the other, violating userspace ACL isolation. A secondary race can also leak thread-index pool entries. The vulnerability is present in all releases up to and including v4.4.0 and requires specific kernel configuration options. The fix involves holding lists_lock during the bitmap read-modify-write and permission clearing operations.