CVE-2026-90087 in Linux
Sumário
de VulDB • 17/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
Bluetooth: não vazar um hci_conn quando uma segunda conexão LE é rejeitada
create_le_conn_complete() decide se a conexão falhada ainda está pendente comparando-a com hci_lookup_le_connect(), que retorna a primeira conexão LE no estado BT_CONNECT. Isso funciona corretamente apenas enquanto houver, no máximo, uma conexão pendente.
Podem haver duas conexões pendentes simultaneamente. Conexões criadas pelo caminho de varredura passiva permanecem em BT_CONNECT com HCI_CONN_SCANNING definido e são invisíveis para hci_lookup_le_connect() até que hci_le_create_conn_sync() limpe a flag quando o comando for emitido; portanto, a proteção contra -EBUSY em hci_connect_le() não impede que uma segunda conexão seja enfileirada enquanto a primeira ainda estiver no caminho de varredura. Sempre que duas conexões estão simultaneamente em BT_CONNECT, a função lookup pode retornar uma conexão enquanto create_le_conn_complete() relata a falha da outra; a saída antecipada então descarta o erro e hci_conn_failed() nunca é executado na conexão que falhou.
O controlador também rejeita um segundo HCI_OP_LE_CREATE_CONN emitido enquanto ainda há uma criação de conexão pendente, conforme especificado no Core Spec Vol 4, Part E. A especificação exige "Command Disallowed" (Comando não permitido) nesse caso; o bcm43438 observado aqui responde com um código de erro LMP/LL em vez disso, que bt_to_errno() mapeia para -EPROTO (-71), conforme registrado abaixo.
A conexão vazada permanece indefinidamente no estado BT_CONNECT e, como hci_connect_le() se recusa a iniciar novas conexões enquanto hci_lookup_le_connect() encontrar qualquer coisa, todas as tentativas subsequentes de alcançar qualquer peer falham com -EBUSY e nenhum comando alcança o controlador.
Observado em um bcm43438 com dois peers BLE sendo consultados no mesmo intervalo (o estado 5 é BT_CONNECT; ambos os handles são UNSET, alocados do ida acima de HCI_CONN_HANDLE_MAX):
Bluetooth: hci1: Opcode 0x2013 falhou: -71
# hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL
Uma captura btmon durante os próximos dez minutos de tentativas de conexão não contém nenhum HCI_OP_LE_CREATE_CONN; as conexões LE de saída não se recuperam até que o adaptador seja reiniciado. Com esta correção, o mesmo cenário rejeita a conexão falhada corretamente e novas conexões com ambos os peers são estabelecidas com sucesso.
Consulte sobre a própria conexão em vez de consultar sobre o dispositivo.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.