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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Fix use-after-free of slot->bus on hot remove Dennis informa un fallo de arranque en portátiles Lenovo recientes con un dock USB4. Desde el commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") y el commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), los routers host USB4 v2 y v1 se restablecen al sondear el controlador Thunderbolt. El restablecimiento borra los bits de estado de detección de presencia y de enlace de capa de enlace de datos activo en el puerto raíz del router host USB4 y, por lo tanto, provoca la eliminación en caliente del dock. El fallo se produce cuando pciehp se desvincula de uno de los puertos de bajada del dock: pciehp crea un pci_slot al vincularlo y lo destruye al desvincularlo. El pci_slot contiene un puntero al pci_bus debajo del puerto de bajada, pero nunca se adquiere una referencia en ese pci_bus. El pci_bus se destruye antes que el pci_slot, por lo que se produce un use-after-free cuando pci_slot_release() accede a slot->bus. En principio, esto no debería suceder porque pci_stop_bus_device() desvincula pciehp (y, por lo tanto, destruye el pci_slot) antes de que pci_remove_bus_device() destruya el pci_bus. Sin embargo, el seguimiento de la pila proporcionado por Dennis muestra que pciehp se desvincula de pci_remove_bus_device() en lugar de pci_stop_bus_device(). Para comprender la importancia de esto, es necesario saber que el núcleo PCI utiliza un proceso de dos pasos para eliminar una parte de la jerarquía: primero desvincula todos los controladores en la subjerarquía en pci_stop_bus_device() y luego elimina los dispositivos en pci_remove_bus_device(). No hay ninguna precaución para evitar la vinculación del controlador entre pci_stop_bus_device() y pci_remove_bus_device(). En el caso de Dennis, parece que la eliminación de la jerarquía por parte de pciehp compite con la vinculación del controlador por parte de pci_bus_add_devices(). pciehp está vinculado al puerto descendente después de que se haya ejecutado pci_stop_bus_device(), por lo que se desvincula mediante pci_remove_bus_device() en lugar de pci_stop_bus_device(). Debido a que pci_bus ya se ha destruido en ese punto, los accesos a él dan como resultado un use-after-free. Se podría concluir que es necesario evitar la vinculación del controlador después de que se haya ejecutado pci_stop_bus_device(). Sin embargo, parece arriesgado que pci_slot apunte a pci_bus sin contener una referencia. Confiar únicamente en el orden correcto de la desvinculación del controlador frente a la destrucción de pci_bus ciertamente no es programación defensiva. Si pci_slot necesita acceder a datos en pci_bus, debe adquirir una referencia. Modifique pci_create_slot() en consecuencia. Dennis informa que el bloqueo no se puede reproducir con este cambio. Rastreo de pila abreviado: pcieport 0000:00:07.0: PME: Señalización con IRQ 156 pcieport 0000:00:07.0: pciehp: Ranura n.º 12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, creó la ranura física 12 pcieport 0000:00:07.0: pciehp: Ranura (12): Tarjeta no presente... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 comando de escritura 0 Oops: error de protección general, probablemente para una dirección no canónica 0x6b6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp No contaminado 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 ranura de destrucción pci pciehp_remove servicio de eliminación de puerto pcie dispositivo de liberación de controlador interno de bus eliminar dispositivo_eliminar_dispositivo anular_registro_dispositivo eliminar_iter dispositivo_para_cada_hijo_eliminar_puerto_pcie dispositivo_eliminar_dispositivo_liberación_controlador_interno_bus_eliminar_dispositivo dispositivo_eliminar pci_remove_bus_device (invocación recursiva) -- truncado----