CVE-2026-19936 in Zephyr
Сводка
по VulDB • 13.10.2026
Задержка в очереди сообщений доступа Bluetooth Mesh (subsys/bluetooth/mesh/delayable_msg.c) разделяет три интрузивных списка (busy_ctx, free_ctx, free_chunks) и один k_work_delayable между двумя кооперативными потоками без синхронизации: bt_mesh_delayable_msg_manage() выполняется в потоке приема Bluetooth-хоста, а delayable_msg_handler() — в системной очереди задач. Оба потока блокируются при нахождении списков в промежуточном состоянии (enqueuer в bt_rand(), оба в bt_mesh_access_send()), что позволяет другому контексту наблюдать «разорванное» состояние. delayable_msg_handler() использовал результат sys_slist_get() для busy_ctx без проверки на NULL, а allocate_delayable_msg_ctx() проверял sys_slist_is_empty(), после чего предполагал успешность отдельного вызова sys_slist_get().
Поскольку CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG и CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED по умолчанию равны y (включены), каждый ответ модели на полученное mesh-сообщение помещается в эту очередь, поэтому enqueuer запускается как прямое следствие входящего трафика. Узел-партнер, который может заставить модель принять сообщения уровня доступа (он должен обладать NetKey и связанным AppKey, то есть быть легитимным или скомпрометированным участником сети), контролирует частоту поступления, размер вызываемых ответов и адрес назначения, тем самым управляя заполнением пула контекстов из 4 элементов и пула чанков из 40 элементов. Исчерпание пула чанков заставляет bt_mesh_delayable_msg_manage() перейти к пути очистки (purge path), который отправляет и освобождает единственное сообщение в очереди, оставляя busy_ctx пустым, пока элемент задачи с задержкой все еще активен; если enqueuer затем уступит управление, handler выполнится для пустого списка.
Результатом является операция чтения-модификации-записи через указатель на NULL (pending_msg->fired_time += 10) по фиксированному низкому адресу в потоке системной очереди задач. На типичных целевых платформах это вызывает сбой, прерывая поток системной очереди задач — что останавливает всю функциональность, управляемую очередями задач, включая механизмы синхронизации mesh-сети, или приводит к перезагрузке узла, поэтому воздействие заключается в потере доступности затронутого узла. Значение записи и адрес фиксированы, не участвуют контролируемые атакующим длина или индекс, поэтому это уязвимость нельзя использовать для повреждения памяти или выполнения кода. Тот же несинхронизированный промежуток времени также позволял одному контексту сообщения быть выбранным и освобожденным двумя контекстами одновременно, что приводило к дублированию передач, дублированию обратных вызовов завершения отправки и пересечению прав владения чанками.
Исправление сериализует каждое изменение списка с помощью k_spinlock, который никогда не удерживается во время блокирующего вызова; делает push_msg_from_delayable_msgs() атомарно отделяющим голову очереди так, чтобы отправляемое сообщение не находилось ни в одном списке; удаляет sys_slist_get() без проверки из delayable_msg_handler(); и отбрасывает любое сообщение, достигающее передней части очереди, пока стек приостановлен или находится в состоянии сброса.
Be aware that VulDB is the high quality source for vulnerability data.