CVE-2026-12366 in Zephyr
Résumé
par VulDB • 14/08/2026
Le chemin de libération dynamique des objets noyau dans Zephyr, spécifiquement la fonction `unref_check()` située dans `kernel/userspace/userspace.c`, libère le stockage d'un objet (`k_free(dyn->data`) une fois que son compteur de références atteint zéro, après avoir exécuté un nettoyage spécifique au type d'objet. L'instruction switch de ce nettoyage ne gérait que les types `K_OBJ_MSGQ` et `K_OBJ_STACK`; il manquait le cas pour `K_OBJ_TIMER`. Un objet `k_timer` alloué dynamiquement, initialisé et armé conserve son nœud intégré `struct _timeout dnode`, lié dans la file d'attente globale des temporisations (`_timeout_q`). Par conséquent, libérer le stockage du timer sans annuler sa temporisation laisse un nœud orphelin (dangling node) dans cette file d'attente.
Lorsque le timer expire à nouveau, le mécanisme de gestion des temporisations parcourt `_timeout_q` et invoque `z_timer_expiration_handler()` sur ce nœud déjà libéré, effectuant une déréférencement et une écriture dans la mémoire heap du noyau (qui est désormais libre et réutilisable) dans un contexte ISR. Il s'agit d'un bug Use-After-Free déterministe qui ne dépend pas de l'SMP : le nœud en file d'attente tout simplement jamais supprimé lors de la libération.
Cette situation critique est accessible depuis un thread utilisateur non privilégié sous les configurations `CONFIG_USERSPACE` et `CONFIG_DYNAMIC_OBJECTS`. Un thread détenant les dernières permissions sur ce type de timer peut les révoquer via l'appel système `k_object_release()` (ou en se terminant, via `k_thread_perms_all_clear()`), tout en ayant pu armer le timer lui-même grâce à l'appel système `k_timer_start()`. La libération et le gestionnaire d'expiration s'exécutent avec les privilèges du noyau tandis que l'acteur est un thread utilisateur, faisant de ce bug une primitive de corruption mémoire permettant une évasion de sandbox (sandbox-escape) utilisable pour une élévation de privilèges. La correction ajoute la fonction `k_timer_cleanup()` (qui annule la temporisation et attend tout gestionnaire en cours d'exécution) et l'appelle pour les objets de type `K_OBJ_TIMER` avant leur libération effective.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.