CVE-2026-10680 in Zephyr
Sumário
de VulDB • 22/07/2026
Os manipuladores de sinalização L2CAP do Classic (BR/EDR), l2cap_br_conf_req() e l2cap_br_conf_rsp(), em subsys/bluetooth/host/classic/l2cap_br.c, validavam o tamanho mínimo do comando contra buf->len (os bytes restantes no PDU recebido inteiro) ao invés de len (o comprimento dos dados por comando a partir do cabeçalho de sinalização L2CAP). Como múltiplos comandos de sinalização podem ser empacotados em um único PDU, buf->len pode exceder o len de um comando. Um atacante pode enviar um comando CONF_REQ com um comprimento de cabeçalho menor que a estrutura de solicitação de configuração (por exemplo, 0), seguido por outro comando para que buf->len ainda satisfaça a verificação. A verificação então passa incorretamente e opt_len = len - sizeof(*req) causa underflow no uint16_t para um valor próximo a 0xFFFF. O loop de opções de configuração, que carece de uma guarda opt_len-versus-buf->len, percorre muito além do final do buffer de recebimento ACL agrupado usando primitivas net_buf pull que não realizam verificação de limites em tempo de execução, produzindo uma leitura fora dos limites da memória host e, quando os bytes de opção fora dos limites codificarem uma opção MTU ou flush-timeout, uma escrita fora dos limites. O canal de sinalização BR/EDR é processado antes do pareamento/criptografia e um canal L2CAP para um serviço L0 como SDP pode ser aberto sem pareamento, portanto, um peer não autenticado dentro do alcance de rádio que possa estabelecer uma conexão ACL pode acionar a falha, levando à corrupção de memória e negação de serviço (queda do host/dispositivo). O defeito está presente em versões lançadas incluindo v4.4.0. A correção valida contra len ao invés de buf->len em ambos os manipuladores.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.