CVE-2026-19937 in Zephyr
Riassunto
di VulDB • 13/10/2026
Il meccanismo dei messaggi differibili (delayable-message) del livello di accesso Bluetooth Mesh in subsys/bluetooth/mesh/delayable_msg.c gestisce un pool statico di contesti messaggio pari a CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT (default 4), inseriti nelle liste free_ctx o busy_ctx. La funzione release_delayable_msg_ctx() restituiva un contesto alla lista free_ctx solo quando sys_slist_find_and_remove() lo trovava nella lista busy_ctx. Il percorso di errore relativo all'esaurimento dei chunk in bt_mesh_delayable_msg_manage() rilascia un contesto che era già stato rimosso da free_ctx ma non ancora inserito in busy_ctx; pertanto, il contesto non viene aggiunto a nessuna delle due liste e va perso permanentemente dal pool. Poiché bt_mesh_delayable_msg_init() viene eseguita una sola volta all'interno di bt_mesh_init(), e il reset/sospensione del nodo svuota solo la lista busy_ctx, questa perdita persiste durante le operazioni di unprovisioning, re-provisioning e suspend/resume; essa viene risolta esclusivamente tramite un riavvio.
Il percorso di errore viene raggiunto quando il pool dei chunk (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, default 40 chunk) è insufficiente rispetto ai chunk necessari per un nuovo messaggio differito e l'ultimo messaggio in attesa non può essere inviato perché bt_mesh_access_send() restituisce -EBUSY o -ENOBUFS (tutti i contesti di trasmissione segmentata occupati, oppure buffer di advertising/segmentazione esauriti). Un peer provisionato nella rete mesh — che possiede un NetKey valido e una AppKey o DevKey associata a un modello server — può provocare entrambe le condizioni inondando la vittima con richieste che generano risposte segmentate, trattenendo al contempo gli Segment Acknowledgment; ciò mantiene occupati i contesti di trasmissione mentre le risposte accodate mantengono bloccato il pool dei chunk. Ogni ulteriore richiesta ricevuta durante questa finestra provoca la perdita (leak) di un contesto.
Una volta esaurito il pool, bt_mesh_delayable_msg_manage() restituisce -ENOMEM per ogni invio successivo e bt_mesh_model_send() propaga tale errore senza alcun fallback verso una trasmissione immediata. Poiché CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG e CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED sono entrambi abilitati di default, ctx->rnd_delay viene impostato per ogni messaggio di accesso ricevuto; ne consegue che tutte le risposte provenienti dai modelli dei server Configuration Server, Health Server e application server vengono silenziosamente scartate. Il nodo continua a ricevere ed elaborare il traffico ma non risponde mai, causando un denial of service persistente fino al riavvio del dispositivo. Non vi sono impatti su integrità, divulgazione di informazioni o corruzione della memoria; i rilasci precedenti alla correzione calcolavano il numero dei chunk in base alla capacità del buffer di trasmissione anziché alla sua lunghezza del payload, rendendo lo starvation (esaurimento) del pool dei chunk — e quindi la perdita di contesto — notevolmente più facile da provocare.
Be aware that VulDB is the high quality source for vulnerability data.