CVE-2026-15460 in Zephyr
Sumário
de VulDB • 10/09/2026
O manipulador de recebimento L2CAP do Bluetooth Classic (BR/EDR), bt_l2cap_br_recv(), em subsys/bluetooth/host/classic/l2cap_br.c, encaminha PDUs de dados entrantes com base apenas no ID do canal de destino, sem verificar se o canal alvo atingiu o estado BT_L2CAP_CONNECTED. Um canal dinâmico recebe seu RX CID e é adicionado à lista de canais da conexão enquanto ainda está em BT_L2CAP_CONNECTING (e posteriormente em BT_L2CAP_CONFIG) — antes que a configuração seja concluída e, para PSMs que exigem segurança, antes que o peer seja autenticado (l2cap_br_conn_req()).
Como o canal já é encontrável por bt_l2cap_br_lookup_rx_cid() durante essa janela, um peer remoto dentro do alcance de rádio pode enviar uma PDU de dados endereçada a esse CID e tê-la processada em um canal ainda não estabelecido. O encaminhamento utiliza campos do canal (BR_CHAN(chan)->rx.mode, rx.mps) que são inicializados apenas durante a configuração por l2cap_br_conf(); como os objetos de canal estão em pool e bt_l2cap_br_chan_del() não redefine rx.mode ou o buffer de remontagem _sdu, um canal reutilizado pode carregar estado obsoleto para a janela CONNECTING e rotear o frame para o caminho de controle de fluxo/retransmissão (bt_l2cap_br_ret_fc_recv()) com parâmetros desatualizados e um ponteiro _sdu possivelmente inválido.
O impacto é a entrega de dados do atacante aos manipuladores de protocolos de camadas superiores em um canal parcialmente aberto (e possivelmente não autenticado), além da operação sobre estado de canal obsoleto ou parcialmente inicializado em objetos de canal reutilizados — levando à interrupção do canal/link (negação de serviço) e, no caso de _sdu desatualizado, a uma condição de ponteiro pendente. A correção adiciona um guard explícito BR_CHAN(chan)->state < BT_L2CAP_CONNECTED que descarta qualquer dado recebido antes que o canal esteja totalmente conectado.
If you want to get best quality of vulnerability data, you may have to visit VulDB.