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 a thread permission index from a global bitmap without holding the necessary lists_lock. On SMP systems, this leads to a race condition where two user-mode threads invoking k_object_alloc(K_OBJ_THREAD) concurrently can receive the same thread index. Consequently, the two threads share the same thread_id, causing them to alias a single bit position in kernel object permission bitfields. This breaks userspace ACL isolation because granting access to one thread implicitly grants it to the other. Additionally, a secondary race can cause leakage of thread-index pool entries. The vulnerability is reachable by any user-mode thread via the unrestricted syscall k_object_alloc and requires CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP to be enabled. It affects all Zephyr releases from 2.0.0 up to and including 4.4.0 and was introduced in 2018. The fix involves holding the lists_lock across the bitmap read-modify-write and permission clearing operations and inlining the object list traversal.
Potential Impact
The vulnerability allows two distinct user-mode threads to share the same thread permission index, resulting in shared access rights to kernel objects. This undermines the userspace access control mechanisms, potentially allowing unauthorized access to kernel objects by threads that should be isolated. The impact includes confidentiality and integrity violations (high impact) and a low impact on availability. The flaw affects systems configured with userspace, dynamic objects, and SMP support. Exploitation requires local user-mode thread access and concurrent syscall invocation.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability is fixed by holding the lists_lock during the allocation of thread permission indices and permission clearing. Until an official fix is applied, avoid running configurations with CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP enabled simultaneously if possible. Monitor vendor channels for an official patch or update. No known exploits are reported in the wild at this time.
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 a thread permission index from a global bitmap without holding the necessary lists_lock. On SMP systems, this leads to a race condition where two user-mode threads invoking k_object_alloc(K_OBJ_THREAD) concurrently can receive the same thread index. Consequently, the two threads share the same thread_id, causing them to alias a single bit position in kernel object permission bitfields. This breaks userspace ACL isolation because granting access to one thread implicitly grants it to the other. Additionally, a secondary race can cause leakage of thread-index pool entries. The vulnerability is reachable by any user-mode thread via the unrestricted syscall k_object_alloc and requires CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP to be enabled. It affects all Zephyr releases from 2.0.0 up to and including 4.4.0 and was introduced in 2018. The fix involves holding the lists_lock across the bitmap read-modify-write and permission clearing operations and inlining the object list traversal.
Potential Impact
The vulnerability allows two distinct user-mode threads to share the same thread permission index, resulting in shared access rights to kernel objects. This undermines the userspace access control mechanisms, potentially allowing unauthorized access to kernel objects by threads that should be isolated. The impact includes confidentiality and integrity violations (high impact) and a low impact on availability. The flaw affects systems configured with userspace, dynamic objects, and SMP support. Exploitation requires local user-mode thread access and concurrent syscall invocation.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vulnerability is fixed by holding the lists_lock during the allocation of thread permission indices and permission clearing. Until an official fix is applied, avoid running configurations with CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP enabled simultaneously if possible. Monitor vendor channels for an official patch or update. No known exploits are reported in the wild at this time.
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: 07/25/2026, 14:07:02 UTC
Last updated: 07/26/2026, 14:41:00 UTC
Views: 24
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.