El subsistema Bluetooth del kernel Linux arrastra un fallo de tipo use-after-free en la ruta SCO, la que gestiona el audio síncrono de manos libres y auriculares. Se le ha asignado el identificador CVE-2026-31408 y una puntuación CVSS de 8.8 (alta).
Qué falla exactamente
El problema está en la función sco_recv_frame(), dentro de net/bluetooth/sco.c. Esta función lee la referencia al socket (conn->sk) bajo el bloqueo sco_conn_lock(), pero suelta el lock inmediatamente sin haber tomado una referencia firme sobre el objeto socket. Entre que libera el bloqueo y el acceso posterior a sk->sk_state, una operación concurrente de cierre (close()) puede liberar ese socket. El resultado es un acceso a memoria ya liberada: un use-after-free clásico provocado por una condición de carrera.
La descripción oficial lo resume así: la función lee conn->sk bajo el lock pero lo libera sin retener una referencia, de modo que un close() concurrente puede liberar el socket antes del siguiente acceso.
A quién afecta
A cualquier sistema Linux con Bluetooth activo. Eso abarca portátiles, equipos de escritorio, dispositivos IoT, sistemas de infoentretenimiento de automoción y un buen número de placas embebidas. El rango de versiones vulnerables es amplio: arranca en la 2.6.12 y llega hasta ramas muy recientes. Según los datos de NVD quedan afectadas, entre otras, todas las series hasta 5.15.203, de 5.16 a 6.1.167, de 6.2 a 6.6.130, de 6.7 a 6.12.79, de 6.13 a 6.18.20 y de 6.19 a 6.19.10. Si mantienes un kernel LTS, mira en qué punto exacto de tu serie entró el arreglo.
Cómo de grave es
El vector CVSS es AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. El AV:A (Adjacent) es importante: no es un fallo explotable desde la otra punta de internet, sino desde la red de proximidad Bluetooth. Un atacante necesita estar dentro del radio de alcance y forzar la condición de carrera entre la recepción de tramas SCO y el cierre del socket. Lograrlo no es trivial, porque depende de la temporización, pero el impacto potencial sí es serio: desde caída del kernel hasta, en el peor caso, ejecución de código. Por eso confidencialidad, integridad y disponibilidad figuran como altas.
La parte tranquilizadora es que el vector de proximidad reduce mucho la superficie frente a un fallo remoto puro. La parte incómoda es que el Bluetooth suele estar encendido por defecto en portátiles y coches.
Mitigación
La corrección introduce un conteo de referencias correcto. Se añade sco_sock_hold() para retener el socket antes de soltar el bloqueo y se llama a sock_put() en todas las rutas de salida, igual que ya hacían otras funciones del mismo fichero. Con eso el socket no puede liberarse mientras sco_recv_frame() lo esté usando.
Qué hacer en la práctica:
- Actualiza el kernel a la primera versión de tu serie que incorpore el parche y reinicia.
- Si por algún motivo no puedes parchear de inmediato y no usas Bluetooth, desactívalo (
rfkill block bluetootho deteniendo el servicio) reduce la exposición a cero mientras tanto. - En flotas de dispositivos IoT o embebidos, prioriza los que tengan Bluetooth siempre activo y al alcance físico de terceros.
Para entender en qué punto de mantenimiento está tu sistema, consulta la ficha de Linux kernel.