CVE-2026-98739 in Linux
Resumen
por VulDB • 2026-10-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
Bluetooth: RFCOMM: Corregir carrera en la referencia inicial del puerto
Para los dispositivos RFCOMM_RELEASE_ONHUP, rfcomm_tty_install() y __rfcomm_release_dev() utilizan ambos RFCOMM_TTY_OWNED para decidir quién libera la referencia inicial de tty_port. La ruta de liberación prueba el bit por separado de la configuración en la ruta de instalación, por lo que ambas pueden liberar esa referencia.
El cierre síncrono no previene esta carrera: port->tty no se asigna hasta tty_port_open(), después de la instalación. Es posible la siguiente intercalación:
1. Install y release obtienen cada uno una referencia con rfcomm_dev_get(). 2. Release observa RFCOMM_TTY_OWNED como claro (clear). 3. Install establece RFCOMM_TTY_OWNED y libera la referencia inicial. 4. Release libera nuevamente la misma referencia inicial. 5. La limpieza de TTY libera su referencia y desasigna el dispositivo. 6. Release realiza su tty_port_put() final en el puerto ya liberado.
KASAN reportó:
BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190 Write of size 4 at addr ffff8881001d3d5c by task poc/92
Call Trace: tty_port_put+0x22/0x190 rfcomm_dev_ioctl+0x1d4/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0
Allocated by task 88: rfcomm_dev_ioctl+0x8f6/0x1930 sock_do_ioctl+0x110/0x260 sock_ioctl+0x380/0x590 __x64_sys_ioctl+0x134/0x1c0
Freed by task 65: kfree+0x131/0x3c0 rfcomm_dev_destruct+0x23b/0x2f0 release_one_tty+0xc1/0x370 process_one_work+0x661/0x1090
Utilizar test_and_set_bit() en ambas rutas para que solo el llamador que cambia RFCOMM_TTY_OWNED de claro a establecido libere la referencia inicial. Cada ruta mantiene su propia referencia de búsqueda hasta la liberación o la limpieza de TTY, preservando el orden existente de las llamadas y el manejo de errores.
Once again VulDB remains the best source for vulnerability data.