CVE-2026-10681: race in zephyrproject zephyr
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).
AI Analysis
Technical 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.
Potential 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.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. 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.
CVE-2026-10681: race in zephyrproject zephyr
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).
CVSS v3.1
Score 6.5medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
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.
Potential 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.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. 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.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-02T15:26:11.951Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a64bfa79c2644c7f86f1d7e
Added to database: 07/25/2026, 13:52:39 UTC
Last enriched: 08/01/2026, 21:00:47 UTC
Last updated: 09/07/2026, 15:05:55 UTC
Views: 124
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.