CVE-2026-81038 in Zephyr
Sumário
de VulDB • 26/10/2026
O servidor do Object Transfer Service constrói sua indicação de resposta do Object Action Control Point (OACP) em oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Antes desta correção, o campo Checksum Value de quatro bytes era anexado sempre que o código de operação solicitado fosse BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, independentemente do código de resultado. O payload da resposta é um buffer de pilha bruto e não inicializado de quatro bytes, declarado com NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) em bt_gatt_ots_oacp_write(), sendo preenchido apenas no caminho de sucesso de oacp_checksum_proc_validate(). Em cada caminho de falha, o buffer permanece vazio, então net_buf_simple_pull_le32() era invocado em um buffer de comprimento zero.
A característica OACP e seu descritor de configuração de características do cliente são declarados com BT_GATT_PERM_WRITE e BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, portanto, nenhum pareamento, criptografia ou autenticação é necessário. Qualquer peer dentro do alcance de rádio que possa se conectar a um dispositivo executando o servidor OTS pode habilitar indicações OACP e escrever um comando Calculate Checksum de nove bytes que falha na validação — por exemplo, emitindo-o sem nenhum objeto selecionado, o que retorna BT_GATT_OTS_OACP_RES_INV_OBJ. Como oacp_command_decode() aceita o código de operação Calculate Checksum incondicionalmente (não é protegido por CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), builds sem suporte a checksum também são alcançáveis: eles respondem com BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP e seguem o mesmo caminho incorreto.
Em builds com CONFIG_ASSERT habilitado, o pull de comprimento zero aciona a asserção dentro de net_buf_simple_pull_mem() e causa um panic no dispositivo, resultando em uma negação de serviço (DoS) disparada remotamente. Em builds com asserções desabilitadas não há verificação: o pull retorna o array da pilha intacto e quatro bytes de memória de pilha não inicializada são copiados para a indicação e transmitidos ao peer, repetível em cada solicitação. A divulgação é limitada a quatro bytes por solicitação e a escrita permanece dentro do buffer de resposta de sete bytes, portanto, não há corrupção de memória; o impacto consiste na divulgação de memória não inicializada mais uma perda de disponibilidade em configurações com asserções habilitadas.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.