CVE-2026-85033 in Zephyr
Sumário
de VulDB • 03/11/2026
O papel de Alvo AVRCP em subsys/bluetooth/host/classic/avrcp.c mantém seu estado de transmissão da resposta dependente do fornecedor em um objeto por conexão selecionado pelo índice de conexão (get_avrcp_tg()), com o contexto por transferência (tid, sent_len e a flag BT_AVRCP_TG_FLAG_TX_ONGOING) armazenados no user_data do net_buf de resposta enfileirada. O manipulador de desmontagem AVCTP avrcp_disconnected() não cancelou tg->vd_rsp_tx_work nem liberou os buffers ainda enfileirados em tg->vd_rsp_tx_pending, portanto uma queda de link no meio de uma resposta fragmentada deixou o buffer na lista com TX_ONGOING ainda definido.
Um Controlador AVRCP remoto pode acionar isso deterministicamente: ele emite um comando dependente do fornecedor cuja resposta excede um único fragmento AVRCP (por exemplo GetElementAttributes ou GetCapabilities), permite que bt_avrcp_tg_vendor_tx_work() emita o fragmento START e, em seguida, interrompe o link ACL em vez de enviar REQUEST_CONTINUING_RESPONSE. O canal de controle AVCTP requer um link BR/EDR criptografado (BT_SECURITY_L2), portanto o atacante deve ser um peer pareado dentro do alcance do rádio; nenhuma interação do usuário é necessária.
Como os objetos Alvo são estáticos e reutilizados, a próxima conexão que cair no mesmo índice de conexão encontra o buffer obsoleto na cabeça da lista vd_rsp_tx_pending. Cada execução do trabalho TX vê TX_ONGOING e retorna imediatamente, portanto todas as respostas subsequentes dependentes do fornecedor ficam enfileiradas atrás da cabeça obsoleta e nunca são enviadas — uma perda persistente das funções do Alvo AVRCP que nenhum timeout corrige e apenas um reboot recupera. Cada ciclo também vaza um buffer de resposta de um pool de aplicação superficial, e um novo peer que envia REQUEST_CONTINUING_RESPONSE limpa o TX_ONGOING obsoleto via bt_avrcp_tg_process_continuing_cmd(), fazendo com que a parte não enviada da resposta do peer anterior seja transmitida para ele.
A correção cancela tg->vd_rsp_tx_work e desreferencia (unrefs) cada buffer em tg->vd_rsp_tx_pending em avrcp_disconnected(); como o contexto TX vive no user_data do buffer, liberar os buffers também redefine a máquina de estado TX. Não há corrupção de memória: o buffer pré-correção é vazado com uma referência ativa, portanto não ocorre use-after-free.
If you want to get best quality of vulnerability data, you may have to visit VulDB.