Vulnerabilidad en kernel de Linux (CVE-2024-44952)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: núcleo del controlador: se corrige uevent_show() frente a la ejecución de desconexión del controlador uevent_show() quiere desreferenciar dev->driver->name. No hay una forma clara de que un atributo de dispositivo desreferenciar dev->driver a menos que ese atributo se defina mediante (struct device_driver).dev_groups. En cambio, el antipatrón de tomar device_lock() en el controlador de atributos corre el riesgo de bloqueos con rutas de código que eliminan los atributos del dispositivo mientras mantienen el bloqueo. Este interbloqueo es típicamente invisible para lockdep dado que device_lock() está marcado como lockdep_set_novalidate_class(), pero algunos subsistemas asignan una clave lockdep local para que @dev->mutex revele informes del formato: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.10.0-rc7+ #275 Tainted: G OE N ------------------------------------------------------ modprobe/2374 está intentando adquirir el bloqueo: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, en: __kernfs_remove+0xde/0x220 pero la tarea ya tiene el bloqueo: ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, en: device_release_driver_internal+0x39/0x210 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&cxl_root_key){+.+.}-{3:3}: __mutex_lock+0x99/0xc30 uevent_show+0xac/0x130 dev_attr_show+0x18/0x40 sysfs_kf_seq_show+0xac/0xf0 seq_read_iter+0x110/0x450 vfs_read+0x25b/0x340 ksys_read+0x67/0xf0 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (kn->active#6){++++}-{0:0}: __lock_acquire+0x121a/0x1fa0 lock_acquire+0xd6/0x2e0 kernfs_drain+0x1e9/0x200 __kernfs_remove+0xde/0x220 kernfs_remove_by_name_ns+0x5e/0xa0 device_del+0x168/0x410 device_unregister+0x13/0x60 devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1c7/0x210 driver_detach+0x47/0x90 bus_remove_driver+0x6c/0xf0 cxl_acpi_exit+0xc/0x11 [cxl_acpi] __do_sys_delete_module.isra.0+0x181/0x260 do_syscall_64+0x75/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Sin embargo, la observación es que los objetos de controlador suelen tener una vida útil mucho más larga que los objetos de dispositivo. Es razonable realizar una desreferencia sin bloqueo de un puntero @driver incluso si está compitiendo por desconectarse de un dispositivo. Dada la poca frecuencia de anulación del registro de un controlador, usesynchronous_rcu() en module_remove_driver() para cerrar cualquier ejecución potencial. Es potencialmente excesivo sufrirsynchronous_rcu() solo para manejar el raro evento uevent_show() de ejecución de eliminación de módulo. Gracias a Tetsuo Handa por el análisis de depuración del informe de syzbot [1].