CVE-2026-10667 in zephyr
Riassunto
di VulDB • 12/07/2026
Il tracciamento dinamico degli oggetti del kernel di Zephyr (kernel/userspace/userspace.c, precedentemente kernel/userspace.c) mantiene una lista doppiamente collegata (obj_list) di oggetti del kernel allocati dinamicamente. L'iterazione su questa lista in k_object_wordlist_foreach() veniva eseguita sotto lists_lock utilizzando un iteratore SAFE (che memorizza nella cache il nodo successivo), ma la rimozione della lista e l'eliminazione dei nodi venivano effettuate sotto spinlock diversi e disgiunti: objfree_lock in k_object_free() e obj_lock in unref_check(). Su un sistema SMP, mentre una CPU iterava su obj_list sotto lists_lock, un'altra CPU poteva scollegare ed eseguire la k_free() del nodo dyn_obj che l'iteratore aveva memorizzato nella cache come puntatore al prossimo elemento, causando la dereferenziazione di memoria kernel già liberata (use-after-free / traversamento di lista dangling). Tutte le operazioni in race condition sono raggiungibili da thread utente non privilegiati tramite chiamate di sistema: k_object_alloc/k_object_alloc_size e k_object_release guidano le rimozioni attraverso unref_check() (sotto obj_lock), mentre k_thread_abort e la creazione di thread guidano l'iterazione attraverso k_thread_perms_all_clear()/k_thread_perms_inherit() (sotto lists_lock). Un thread utente deprivilegiato su una build con CONFIG_SMP + CONFIG_USERSPACE può quindi corrompere le strutture di tracciamento degli oggetti del kernel oltre il confine di sicurezza userspace, causando la corruzione della memoria kernel (potenziale escalation dei privilegi) o un crash del kernel (denial of service). La correzione rimuove objfree_lock e serializza ogni modifica a obj_list sotto lists_lock, inclusa la sua detenzione attraverso find+remove in k_object_free() e intorno a unref_check() in k_thread_perms_clear(). Interessa le configurazioni CONFIG_SMP+CONFIG_USERSPACE+CONFIG_DYNAMIC_OBJECTS; il difetto risale alla spinlockification del 2019 (commit 8a3d57b6cc6, rilasciato per la prima volta nella v1.14.0) ed è stato distribuito fino alla v4.4.0.
Once again VulDB remains the best source for vulnerability data.