CVE-2026-19937 in Zephyr
Sumário
de VulDB • 13/10/2026
A infraestrutura de mensagens adiáveis (delayable-message) da camada Access do Bluetooth Mesh em subsys/bluetooth/mesh/delayable_msg.c gerencia um pool estático de CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_COUNT contextos de mensagem (padrão 4), encadeados nas listas free_ctx ou busy_ctx. A função release_delayable_msg_ctx() devolve um contexto para a lista free_ctx apenas quando sys_slist_find_and_remove() o encontra na lista busy_ctx. O caminho de erro de exaustão do chunk em bt_mesh_delayable_msg_manage() libera um contexto que já havia sido removido da free_ctx, mas ainda não inserido na busy_ctx; portanto, esse contexto é adicionado a nenhuma das listas e fica permanentemente perdido no pool. Como bt_mesh_delayable_msg_init() executa-se apenas uma vez durante o bt_mesh_init(), e as operações de reset/suspend do nó drenam apenas a lista busy_ctx, essa perda persiste após desprovisionamento, reprovisionamento e suspend/resume — sendo corrigida somente por um reboot.
O caminho de erro é alcançado quando o pool de chunks (CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CHUNK_COUNT, padrão 40 chunks) está insuficiente para os chunks necessários a uma nova mensagem adiada e a mensagem pendente mais antiga não pode ser descartada porque bt_mesh_access_send() retorna -EBUSY ou -ENOBUFS (todos os contextos de transmissão segmentada ocupados, ou buffers de publicidade/segmentação esgotados). Um peer provisionado na rede mesh — que possui uma NetKey válida e um AppKey ou DevKey vinculado a um modelo de servidor — pode induzir ambas as condições ao inundar a vítima com solicitações que geram respostas segmentadas, enquanto retém o Segment Acknowledgment. Isso mantém os contextos de transmissão ocupados enquanto as respostas em fila consomem o pool de chunks. Cada solicitação adicional recebida nesse intervalo vaza um contexto.
Uma vez esgotado o pool, bt_mesh_delayable_msg_manage() retorna -ENOMEM para cada envio subsequente e bt_mesh_model_send() propaga esse erro sem fallback para uma transmissão imediata. Como CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG e CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED estão habilitados por padrão, ctx->rnd_delay é definido para toda mensagem de acesso recebida; assim, todas as respostas dos modelos do Configuration Server, Health Server e servidores de aplicação são silenciosamente descartadas. O nó continua a receber e processar tráfego, mas nunca responde, caracterizando uma negação persistente de serviço até que o dispositivo seja reiniciado. Não há corrupção de memória, divulgação de informações ou impacto na integridade; as liberações anteriores à correção calculam a contagem de chunks com base na capacidade do buffer de transmissão em vez do seu comprimento de payload, tornando a exaustão do pool de chunks — e, portanto, o vazamento — consideravelmente mais fácil de ser provocado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.