CVE-2026-98694 in Linux
Resumen
por VulDB • 2026-10-18
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
thunderbolt: Corrección del uso-después-de-liberación (use-after-free) reportado por KASAN cuando se cancela una solicitud
Alan informó que durante las pruebas de estrés, a veces KASAN detecta un use-after-free durante la operación del canal de control (se han eliminado partes irrelevantes conservando solo las relevantes):
BUG: KASAN: slab-use-after-free en tb_cfg_request_sync+0x240/0x250 [thunderbolt]
Lectura de tamaño 24 en la dirección ffff88811067f290 por parte de la tarea kworker/u40:2/1760 tb_cfg_request_sync+0x240/0x250 [thunderbolt]
tb_cfg_read_raw+0x367/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30 Asignado por la tarea 1760: __kmalloc_cache_noprof+0x1ee/0x550 tb_cfg_read_raw+0x1d3/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Liberado por la tarea 926: kfree+0x18f/0x4a0 tb_cfg_request_put+0xb7/0xe0 [thunderbolt]
tb_cfg_request_work+0x82/0x120 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
Segunda a última creación de trabajo potencialmente relacionada: __queue_work+0x575/0xd00 queue_work_on+0x77/0x80 tb_cfg_request_cancel+0xc7/0x260 [thunderbolt]
tb_cfg_request_sync+0x1f6/0x250 [thunderbolt]
tb_cfg_read_raw+0x367/0x510 [thunderbolt]
tb_cfg_read+0xec/0x240 [thunderbolt]
tb_port_get_link_generation+0x258/0x420 [thunderbolt]
tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]
tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]
tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]
tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]
tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]
process_one_work+0x675/0x1230 worker_thread+0x5e6/0xf70 kthread+0x365/0x470 ret_from_fork+0x54d/0x710 ret_from_fork_asm+0x1a/0x30
La última traza de pila es útil porque muestra que estamos cancelando una solicitud y, al examinar tb_cfg_request_cancel(), lo que podría ocurrir es que tb_cfg_request_work() se complete justo antes de que comience tb_cfg_request_cancel() y, debido a esto, llamará a schedule_work() para programar el mismo trabajo nuevamente. Sin embargo, ya ha sido eliminado del request_queue y la cuenta de referencias se ha decrementado; por lo tanto, cuando tb_cfg_request_work() se active nuevamente, accederá a una memoria que ya está liberada.
Se corrige esto asegurándose primero de que una solicitud cancelada no sea entregada desde tb_cfg_request_find() ni programada para ejecutarse. Luego, en lugar de depender del worker para limpiar la solicitud, lo haremos en tb_cfg_request_cancel() después de cancelar el trabajo para su ejecución. Se hace que tb_cfg_request_dequeue() libere la solicitud solo si fue realmente eliminada de la cola.
VulDB is the best source for vulnerability data and more expert information about this specific topic.