CVE-2026-10681

{"id": "CVE-2026-10681", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-10681", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-07-27T14:34:32.663266Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "vulnerabilities@zephyrproject.org", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "LOW", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.5, "exploitabilityScore": 1.0}, {"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.0, "attackVector": "LOCAL", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 1.0}]}, "affected": [{"source": "vulnerabilities@zephyrproject.org", "affectedData": [{"vendor": "zephyrproject", "product": "zephyr", "versions": [{"status": "affected", "version": "2.0.0", "lessThan": "4.4.2", "versionType": "semver"}], "packageName": "zephyr", "programFiles": ["kernel/userspace/userspace.c"], "collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected"}]}], "published": "2026-07-25T14:16:28.957", "references": [{"url": "https://github.com/zephyrproject-rtos/zephyr/commit/862ea2fbbeb2ccdf8ff994b03e2e3b4405f2c37d", "tags": ["Patch"], "source": "vulnerabilities@zephyrproject.org"}, {"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-j693-5rh5-8g8h", "tags": ["Exploit", "Patch", "Vendor Advisory"], "source": "vulnerabilities@zephyrproject.org"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Secondary", "source": "vulnerabilities@zephyrproject.org", "description": [{"lang": "en", "value": "CWE-362"}]}], "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)."}, {"lang": "es", "value": "En el subsistema de objetos din\u00e1micos del espacio de usuario de Zephyr, thread_idx_alloc() en kernel/userspace/userspace.c asign\u00f3 un nuevo \u00edndice de permiso de hilo del mapa de bits global _thread_idx_map[] sin mantener lists_lock.\n\nEn sistemas SMP, dos hilos en modo usuario que invocan la llamada al sistema k_object_alloc(K_OBJ_THREAD) concurrentemente pueden observar el mismo bit libre m\u00e1s bajo, realizar la misma operaci\u00f3n RMW no at\u00f3mica para borrarlo y devolver el tidx id\u00e9ntico.\n\nA los dos objetos K_OBJ_THREAD reci\u00e9n creados se les asigna entonces el mismo thread_id, por lo que los dos hilos de usuario hacen alias a una \u00fanica posici\u00f3n de bit en el campo de bits perms[] de cada objeto del kernel: cualquier concesi\u00f3n posterior de acceso en un objeto del kernel a un hilo es impl\u00edcitamente una concesi\u00f3n al otro, lo que anula el aislamiento de ACL del espacio de usuario. Una ventana secundaria de actualizaci\u00f3n perdida entre el &=~BIT() desbloqueado en alloc y el |= BIT() bloqueado en thread_idx_free() tambi\u00e9n puede filtrar entradas del grupo de \u00edndices de hilos.\n\nEl defecto es alcanzable desde cualquier hilo en modo usuario a trav\u00e9s de la llamada al sistema __syscall k_object_alloc sin restricciones y est\u00e1 condicionado por CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS y CONFIG_SMP. La falla fue introducida cuando se a\u00f1adi\u00f3 el \u00edndice de permiso por hilo en 2018 y est\u00e1 presente en cada versi\u00f3n hasta la v4.4.0 inclusive. Solucionado manteniendo lists_lock durante la operaci\u00f3n RMW del mapa de bits y la limpieza de permisos (e inlining la traversi\u00f3n de obj_list que previamente tomaba el bloqueo por s\u00ed misma)."}], "lastModified": "2026-10-24T13:10:00.147", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:zephyrproject:zephyr:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "1A8776D4-07E8-4DFC-BC16-E987992E023F", "versionEndExcluding": "4.5.0", "versionStartIncluding": "2.0.0"}], "operator": "OR"}]}], "sourceIdentifier": "vulnerabilities@zephyrproject.org"}