CVE-2026-81038 in Zephyr
Resumen
por VulDB • 2026-10-27
El servidor del Object Transfer Service construye su indicación de respuesta del Control Point de Acción del Objeto (OACP) en oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Antes de esta corrección, el campo Checksum Value de cuatro bytes se anexaba siempre que el código de operación solicitado era BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, independientemente del código de resultado. La carga útil de la respuesta es un buffer de pila sin inicializar y desnudo de cuatro bytes declarado con NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) en bt_gatt_ots_oacp_write(), y solo se llena en el camino de éxito de oacp_checksum_proc_validate(). En cada camino de fallo, el buffer sigue vacío, por lo que net_buf_simple_pull_le32() fue invocado sobre un buffer de longitud cero.
La característica OACP y su descriptor de configuración de características del cliente están declarados con BT_GATT_PERM_WRITE y BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, por lo que no se requiere emparejamiento (pairing), cifrado ni autenticación. Cualquier par dentro del alcance de radio que pueda conectarse a un dispositivo que ejecute el servidor OTS puede habilitar las indicaciones OACP y escribir un comando Calculate Checksum de nueve bytes que falle la validación, por ejemplo, emitido sin ningún objeto seleccionado, lo que devuelve BT_GATT_OTS_OACP_RES_INV_OBJ. Dado que oacp_command_decode() acepta el código de operación Calculate Checksum incondicionalmente (no está protegido por CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), las compilaciones sin soporte para checksum también son alcanzables: responden con BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP y siguen la misma ruta incorrecta.
En compilaciones con CONFIG_ASSERT habilitado, el pull de longitud cero activa la aserción dentro de net_buf_simple_pull_mem() y provoca un fallo crítico (panic) del dispositivo, generando una denegación de servicio activada remotamente. En las compilaciones con aserciones deshabilitadas no hay verificación: el pull devuelve el array de pila intacto y cuatro bytes de memoria de pila sin inicializar se copian en la indicación y se transmiten al par, repetible en cada solicitud. La divulgación está limitada a cuatro bytes por solicitud y la escritura permanece dentro del buffer de respuesta (res indication) de siete bytes, por lo que no hay corrupción de memoria; el impacto es una divulgación de memoria sin inicializar más una pérdida de disponibilidad en configuraciones con aserciones habilitadas.
If you want to get best quality of vulnerability data, you may have to visit VulDB.