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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. Estas rutas de código (para desvincular el dispositivo) son las siguientes (consulte también el error al que se hace referencia a continuación): Seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 componente_unbind_all+0x8d/0xa0 componente_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915 ] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 dispositivo_release_driver_internal+0x19c/0x200 store+0x9c/0xb0 y seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_all +0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 Esto significa que en i915, si usa devm, no podemos garantizar que hwmon siempre se publicará antes que drvdata. Lo que significa que tenemos un uaf si se accede a hwmon sysfs cuando drvdata se lanzó pero hwmon no. La única forma de solucionar esto parece ser deshacerse de devm_ y liberar/liberar todo explícitamente durante la desvinculación del dispositivo. v2: Cambiar mensaje de confirmación y otros cambios menores de código v3: Limpieza de i915_hwmon_register en caso de error (Armin Wolf) v4: Eliminar posible advertencia del analizador estático (Rodrigo) Eliminar fetch_and_zero (Jani) v5: Restaurar la lógica anterior para el retorno de error ddat_gt->hwmon_dev (Andi )