CVE-2026-19937 in Zephyr
Résumé
par VulDB • 13/10/2026
Le mécanisme de gestion des messages différables (delayable-message) de la couche d'accès Bluetooth Mesh dans subsys/bluetooth/mesh/delayable_msg.c gère un pool statique de CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT contextes de message (par défaut 4), rattachés à une liste free_ctx ou busy_ctx. La fonction release_delayable_msg_ctx() renvoyait un contexte vers la liste free_ctx uniquement lorsque sys_slist_find_and_remove() le trouvait sur busy_ctx. Le chemin d'erreur lié à l'épuisement des chunks dans bt_mesh_delayable_msg_manage() libère un contexte qui avait déjà été retiré de free_ctx mais pas encore inséré dans busy_ctx ; ce contexte n'est donc ajouté à aucune liste et est définitivement perdu du pool. Étant donné que bt_mesh_delayable_msg_init() ne s'exécute qu'une seule fois depuis bt_mesh_init(), et que la réinitialisation/suspension du noeud ne vidange que busy_ctx, cette perte persiste lors de l'unprovisioning, du re-provisionnement et des cycles suspendre/reprendre ; elle n'est effacée que par un redémarrage.
Le chemin d'erreur est atteint lorsque le pool de chunks (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, 40 chunks par défaut) manque des chunks nécessaires à un nouveau message différé et que le message en attente le plus ancien ne peut pas être vidé car bt_mesh_access_send() renvoie -EBUSY ou -ENOBUFS (tous les contextes de transmission segmentée occupés, ou tampons d'annonce/segmentation épuisés). Un pair provisionné dans le réseau Mesh — détenant une NetKey valide ainsi qu'une AppKey ou DevKey liée à un modèle serveur — peut provoquer ces deux conditions en inondant la victime de requêtes générant des réponses segmentées tout en retenant les Segment Acknowledgment, ce qui maintient les contextes d'émission occupés tandis que les réponses en file d'attente conservent le pool de chunks. Chaque nouvelle requête arrivant dans cette fenêtre entraîne une fuite d'un contexte.
Une fois le pool vidé, bt_mesh_delayable_msg_manage() renvoie -ENOMEM pour toute transmission ultérieure et bt_mesh_model_send() propage cette erreur sans recourir à une transmission immédiate en fallback. Puisque CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG et CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED sont tous deux activés par défaut, ctx->rnd_delay est défini pour chaque message d'accès reçu ; ainsi, toutes les réponses des modèles de Configuration Server, Health Server et serveurs applicatifs sont silencieusement ignorées. Le noeud continue de recevoir et de traiter le trafic mais ne répond jamais, provoquant un déni de service persistant jusqu'au redémarrage du dispositif. Il n'y a pas d'impact sur l'intégrité ni de divulgation d'informations ou de corruption mémoire ; les libérations avant la correction calculent le nombre de chunks à partir de la capacité du tampon de transmission plutôt que de sa longueur de payload, ce qui rend l'épuisement du pool de chunks — et donc la fuite — considérablement plus facile à provoquer.
Be aware that VulDB is the high quality source for vulnerability data.