{"api_version":"1","generated_at":"2026-07-25T20:35:53+00:00","cve":"CVE-2026-10681","urls":{"html":"https://cve.report/CVE-2026-10681","api":"https://cve.report/api/cve/CVE-2026-10681.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-10681","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-10681"},"summary":{"title":"SMP race in `thread_idx_alloc()` lets concurrent `k_object_alloc(K_OBJ_THREAD)` callers share a kernel-object permission slot","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.\n\nOn 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.\n\nThe 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.\n\nThe 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).","state":"PUBLISHED","assigner":"zephyr","published_at":"2026-07-25 14:16:28","updated_at":"2026-07-25 14:16:28"},"problem_types":["CWE-362","CWE-362 race"],"metrics":[{"version":"3.1","source":"vulnerabilities@zephyrproject.org","type":"Secondary","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","data":{"baseScore":6.5,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","version":"3.1"}}],"references":[{"url":"https://github.com/zephyrproject-rtos/zephyr/commit/862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d","name":"https://github.com/zephyrproject-rtos/zephyr/commit/862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j693-5rh5-8g8h","name":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j693-5rh5-8g8h","refsource":"vulnerabilities@zephyrproject.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-10681","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-10681","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"zephyrproject","product":"zephyr","version":"affected 2.0.0 4.5.0 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://github.com/zephyrproject-rtos/zephyr","defaultStatus":"unaffected","packageName":"zephyr","product":"zephyr","programFiles":["kernel/userspace/userspace.c"],"vendor":"zephyrproject","versions":[{"lessThan":"4.5.0","status":"affected","version":"2.0.0","versionType":"semver"}]}],"descriptions":[{"lang":"en","value":"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.\n\nOn 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.\n\nThe 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.\n\nThe 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)."}],"metrics":[{"cvssV3_1":{"baseScore":6.5,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","version":"3.1"},"format":"CVSS"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-362","description":"race","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-07-25T13:23:07.028Z","orgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","shortName":"zephyr"},"references":[{"name":"Fix commit","tags":["patch"],"url":"https://github.com/zephyrproject-rtos/zephyr/commit/862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d"},{"name":"GHSA-j693-5rh5-8g8h","url":"https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j693-5rh5-8g8h"}],"title":"SMP race in `thread_idx_alloc()` lets concurrent `k_object_alloc(K_OBJ_THREAD)` callers share a kernel-object permission slot","x_generator":{"engine":"cvelib 1.8.0"}}},"cveMetadata":{"assignerOrgId":"e2e69745-5e70-4e92-8431-deb5529a81ad","assignerShortName":"zephyr","cveId":"CVE-2026-10681","datePublished":"2026-07-25T13:23:07.028Z","dateReserved":"2026-06-02T15:26:11.951Z","dateUpdated":"2026-07-25T13:23:07.028Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-25 14:16:28","lastModifiedDate":"2026-07-25 14:16:28","problem_types":["CWE-362","CWE-362 race"],"metrics":{"cvssMetricV31":[{"source":"vulnerabilities@zephyrproject.org","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"},"exploitabilityScore":1,"impactScore":5.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"10681","Ordinal":"1","Title":"SMP race in `thread_idx_alloc()` lets concurrent `k_object_alloc","CVE":"CVE-2026-10681","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"10681","Ordinal":"1","NoteData":"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.\n\nOn 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.\n\nThe 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.\n\nThe 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).","Type":"Description","Title":"SMP race in `thread_idx_alloc()` lets concurrent `k_object_alloc"}]}}}