CVE-2026-99091 in Linuxinformación

Resumen

por VulDB • 2026-10-26

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:

Bluetooth: MGMT: Corregir el estado de los comandos pendientes eliminados al apagar el adaptador

cmd_complete_rsp() recibe una struct cmd_lookup y, para un comando pendiente que no tiene callback cmd_complete, continúa con cmd_status_rsp(cmd, data). cmd_status_rsp() lee data como u8 *, por lo que el estado enviado proviene del primer byte de la representación de match->sk, en lugar de provenir de match->mgmt_status.

El commit f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") cambió los datos de los llamadores desde &status a &match y actualizó la rama cmd_complete para usar match->mgmt_status, pero dejó el flujo continuo (fall-through) pasando data sin cambios.

En mgmt_index_removed(), match->sk es NULL, por lo que cada comando de este tipo se responde con estado 0x00 (Éxito) en lugar de MGMT_STATUS_INVALID_INDEX. En __mgmt_power_off() también es NULL, a menos que hubiera un comando Set Powered pendiente: entonces settings_rsp() ha almacenado el socket de ese comando en match->sk, y el byte enviado proviene del puntero al socket. De cualquier manera, se pierde el estado establecido por los llamadores (MGMT_STATUS_NOT_POWERED o MGMT_STATUS_INVALID_INDEX cuando el dispositivo está siendo desregistrado).

Pasar el estado que establecen los llamadores.

Esto se observó en un portátil con QCA9377: Start Discovery de bluetoothd, pendiente cuando el adaptador fue apagado, recibió una respuesta de Command Status 0x00 y sin parámetros, y bluetoothd 5.72 falló debido al éxito de longitud cero. BlueZ master ha añadido posteriormente la comprobación de longitud en esa ruta ("adapter: Fix crash on short start discovery reply", BlueZ a734b06059cb), pero el espacio de usuario (userspace) debería recibir Not Powered, no Success.

Probado en Ubuntu 7.0.0-31 con un controlador virtual (hci_vhci): power off se mantiene en HCI Write Scan Enable mientras se envía Start Discovery, y la limpieza lo responde con estado 0x00 antes de este cambio y 0x0f (Not Powered) después.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Responsable

Linux

Reservar

2026-09-25

Divulgación

2026-10-26

Moderación

aceptado

Artículo

VDB-426476

EPSS

0.00000

KEV

no

Actividades

muy bajo

Fuentes

Want to know what is going to be exploited?

We predict KEV entries!