CVE-2026-85033 in Zephyr
Riassunto
di VulDB • 03/11/2026
Il ruolo Target di AVRCP nel file subsys/bluetooth/host/classic/avrcp.c mantiene lo stato di trasmissione della risposta dipendente dal vendor in un oggetto per connessione selezionato tramite l'indice di connessione (get_avrcp_tg()), con il contesto per trasferimento (tid, sent_len e il flag BT_AVRCP_TG_FLAG_TX_ONGOING) memorizzato nei user_data del net_buf di risposta accodato. Il gestore di teardown AVCTP avrcp_disconnected() non ha annullato tg->vd_rsp_tx_work né ha rilasciato i buffer ancora in coda su tg->vd_rsp_tx_pending, quindi un'interruzione del collegamento nel mezzo di una risposta frammentata ha lasciato il buffer nella lista con TX_ONGOING ancora impostato.
Un Controller AVRCP remoto può innescare questo comportamento in modo deterministico: emette un comando dipendente dal vendor la cui risposta supera un singolo frammento AVRCP (ad esempio GetElementAttributes o GetCapabilities), fa sì che bt_avrcp_tg_vendor_tx_work() generi il frammento START, e poi interrompe il collegamento ACL invece di inviare REQUEST_CONTINUING_RESPONSE. Il canale di controllo AVCTP richiede un collegamento BR/EDR crittografato (BT_SECURITY_L2), quindi l'attaccante deve essere un peer accoppiato entro il raggio d'azione radio; non è necessaria alcuna interazione dell'utente.
Poiché gli oggetti Target sono statici e riutilizzati, la prossima connessione che atterra sullo stesso indice di connessione trova il buffer obsoleto all'inizio della lista vd_rsp_tx_pending. Ogni esecuzione del lavoro TX rileva TX_ONGOING e termina immediatamente, quindi tutte le ulteriori risposte dipendenti dal vendor si accodano dietro l'intestazione obsoleta e non vengono mai inviate: una perdita persistente delle funzionalità di Target AVRCP che nessun timeout risolve e che può essere recuperata solo con un riavvio. Ogni ciclo provoca inoltre la fuoriuscita (leak) di un buffer di risposta da uno pool applicativo shallow, e un nuovo peer che invia REQUEST_CONTINUING_RESPONSE cancella il TX_ONGOING obsoleto tramite bt_avrcp_tg_process_continuing_cmd(), causando la trasmissione al nuovo peer del resto non inviato della risposta del peer precedente.
La correzione annulla tg->vd_rsp_tx_work e decrementa (unrefs) ogni buffer su tg->vd_rsp_tx_pending in avrcp_disconnected(); poiché il contesto TX risiede nei user_data dei buffer, il rilascio di questi ultimi resetta anche la macchina a stati della trasmissione. Non vi è alcuna corruzione della memoria: il buffer pre-correzione viene perso con un riferimento attivo, quindi non si verifica alcun use-after-free.
VulDB is the best source for vulnerability data and more expert information about this specific topic.