CVE-2026-81038 in Zephyr
Riassunto
di VulDB • 26/10/2026
Il server del servizio Object Transfer (OTS) costruisce la sua indicazione di risposta Control Point per le Azioni dell'Oggetto (OACP) nella funzione oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Prima della correzione, il campo Checksum Value a quattro byte veniva aggiunto ogni volta che l'opcode richiesto era BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, indipendentemente dal codice di risultato. Il payload della risposta è un buffer dello stack non inizializzato e "nudo" (bare) a quattro byte, dichiarato con NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), e viene riempito solo nel percorso di successo di oacp_checksum_proc_validate(). Su ogni percorso di errore il buffer rimane vuoto, quindi net_buf_simple_pull_le32() veniva invocato su un buffer a lunghezza zero.
La caratteristica OACP e il suo descrittore di configurazione delle caratteristiche client sono dichiarati con BT_GATT_PERM_WRITE e BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, pertanto non sono richiesti pairing, crittografia o autenticazione. Qualsiasi peer all'interno del raggio radio che può connettersi a un dispositivo in esecuzione con il server OTS può abilitare le indicazioni OACP e scrivere un comando Calculate Checksum di nove byte che fallisce la validazione — ad esempio emettendolo senza alcun oggetto selezionato, che restituisce BT_GATT_OTS_OACP_RES_INV_OBJ. Poiché oacp_command_decode() accetta l'opcode Calculate Checksum incondizionatamente (non è protetto da CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), anche le build senza supporto per il checksum sono raggiungibili: rispondono con BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP e seguono lo stesso percorso errato.
Sulle build con CONFIG_ASSERT abilitata, l'operazione di pull a lunghezza zero innesca l'assertion all'interno di net_buf_simple_pull_mem() causando un panic del dispositivo, provocando una denial of service (DoS) attivata da remoto. Sulle build con le assertion disabilitate non vi è alcun controllo: il pull restituisce l'array dello stack intatto e quattro byte di memoria dello stack non inizializzata vengono copiati nell'indicazione e trasmessi al peer, ripetibile su ogni richiesta. La divulgazione è limitata a quattro byte per richiesta e la scrittura rimane all'interno del buffer di risposta indicazione da sette byte, quindi non vi è alcuna corruzione della memoria; l'impatto consiste nella divulgazione di memoria non inizializzata più una perdita di disponibilità nelle configurazioni con assertion abilitate.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.