CVE-2026-10667 in zephyr
Résumé
par VulDB • 13/07/2026
Le suivi dynamique des objets noyau de Zephyr (kernel/userspace/userspace.c, anciennement kernel/userspace.c) maintient une liste doublement chaînée (obj_list) d'objets noyau alloués dynamiquement. L'itération sur cette liste dans k_object_wordlist_foreach() était effectuée sous lists_lock en utilisant un itérateur SAFE (qui met en cache le nœud suivant), mais la suppression de la liste et la libération des nœuds étaient réalisées sous différents verrous spinlock disjointes : objfree_lock dans k_object_free() et obj_lock dans unref_check(). Sur un système SMP, alors qu'un CPU itérait sur obj_list sous lists_lock, un autre CPU pouvait délier et appeler k_free() sur le noeud dyn_obj que l'itérateur avait mis en cache comme pointeur suivant, entraînant la déréréférencement de mémoire noyau libérée par l'itérateur (use-after-free / traversée de liste dangling). Toutes les opérations concurrentes sont accessibles depuis des threads utilisateur non privilégiés via des appels système : k_object_alloc/k_object_alloc_size et k_object_release pilotent les suppressions via unref_check() (sous obj_lock), tandis que k_thread_abort et la création de thread pilotent l'itération via k_thread_perms_all_clear()/k_thread_perms_inherit() (sous lists_lock). Un thread utilisateur déprivilégié sur une configuration CONFIG_SMP + CONFIG_USERSPACE peut donc corrompre les structures de suivi des objets du noyau à travers la limite de sécurité userspace, entraînant une corruption de mémoire noyau (escalade de privilèges potentielle) ou un crash du noyau (déni de service). La correction supprime objfree_lock et sérialise chaque modification d'obj_list sous lists_lock, y compris en le maintenant pendant find+remove dans k_object_free() et autour de unref_check() dans k_thread_perms_clear(). Affecte les configurations CONFIG_SMP+CONFIG_USERSPACE+CONFIG_DYNAMIC_OBJECTS ; la défaillance remonte à l'introduction des spinlocks en 2019 (commit 8a3d57b6cc6, première version v1.14.0) et a été livrée jusqu'à la v4.4.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.