nvd-json-data-feeds/CVE-2024/CVE-2024-531xx/CVE-2024-53194.json

{
  "id": "CVE-2024-53194",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "published": "2024-12-27T14:15:27.007",
  "lastModified": "2024-12-27T14:15:27.007",
  "vulnStatus": "Awaiting Analysis",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix use-after-free of slot->bus on hot remove\n\nDennis reports a boot crash on recent Lenovo laptops with a USB4 dock.\n\nSince commit 0fc70886569c (\"thunderbolt: Reset USB4 v2 host router\") and\ncommit 59a54c5f3dbd (\"thunderbolt: Reset topology created by the boot\nfirmware\"), USB4 v2 and v1 Host Routers are reset on probe of the\nthunderbolt driver.\n\nThe reset clears the Presence Detect State and Data Link Layer Link Active\nbits at the USB4 Host Router's Root Port and thus causes hot removal of the\ndock.\n\nThe crash occurs when pciehp is unbound from one of the dock's Downstream\nPorts:  pciehp creates a pci_slot on bind and destroys it on unbind.  The\npci_slot contains a pointer to the pci_bus below the Downstream Port, but\na reference on that pci_bus is never acquired.  The pci_bus is destroyed\nbefore the pci_slot, so a use-after-free ensues when pci_slot_release()\naccesses slot->bus.\n\nIn principle this should not happen because pci_stop_bus_device() unbinds\npciehp (and therefore destroys the pci_slot) before the pci_bus is\ndestroyed by pci_remove_bus_device().\n\nHowever the stacktrace provided by Dennis shows that pciehp is unbound from\npci_remove_bus_device() instead of pci_stop_bus_device().  To understand\nthe significance of this, one needs to know that the PCI core uses a two\nstep process to remove a portion of the hierarchy:  It first unbinds all\ndrivers in the sub-hierarchy in pci_stop_bus_device() and then actually\nremoves the devices in pci_remove_bus_device().  There is no precaution to\nprevent driver binding in-between pci_stop_bus_device() and\npci_remove_bus_device().\n\nIn Dennis' case, it seems removal of the hierarchy by pciehp races with\ndriver binding by pci_bus_add_devices().  pciehp is bound to the\nDownstream Port after pci_stop_bus_device() has run, so it is unbound by\npci_remove_bus_device() instead of pci_stop_bus_device().  Because the\npci_bus has already been destroyed at that point, accesses to it result in\na use-after-free.\n\nOne might conclude that driver binding needs to be prevented after\npci_stop_bus_device() has run.  However it seems risky that pci_slot points\nto pci_bus without holding a reference.  Solely relying on correct ordering\nof driver unbind versus pci_bus destruction is certainly not defensive\nprogramming.\n\nIf pci_slot has a need to access data in pci_bus, it ought to acquire a\nreference.  Amend pci_create_slot() accordingly.  Dennis reports that the\ncrash is not reproducible with this change.\n\nAbridged stacktrace:\n\n  pcieport 0000:00:07.0: PME: Signaling with IRQ 156\n  pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+\n  pci_bus 0000:20: dev 00, created physical slot 12\n  pcieport 0000:00:07.0: pciehp: Slot(12): Card not present\n  ...\n  pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0\n  Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1\n  RIP: 0010:dev_driver_string+0x12/0x40\n  pci_destroy_slot\n  pciehp_remove\n  pcie_port_remove_service\n  device_release_driver_internal\n  bus_remove_device\n  device_del\n  device_unregister\n  remove_iter\n  device_for_each_child\n  pcie_portdrv_remove\n  pci_device_remove\n  device_release_driver_internal\n  bus_remove_device\n  device_del\n  pci_remove_bus_device (recursive invocation)\n  pci_remove_bus_device\n  pciehp_unconfigure_device\n  pciehp_disable_slot\n  pciehp_handle_presence_or_link_change\n  pciehp_ist"
    },
    {
      "lang": "es",
      "value": "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\u00e1tiles 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\u00f3n de presencia y de enlace de capa de enlace de datos activo en el puerto ra\u00edz del router host USB4 y, por lo tanto, provoca la eliminaci\u00f3n 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\u00eda 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\u00facleo PCI utiliza un proceso de dos pasos para eliminar una parte de la jerarqu\u00eda: primero desvincula todos los controladores en la subjerarqu\u00eda en pci_stop_bus_device() y luego elimina los dispositivos en pci_remove_bus_device(). No hay ninguna precauci\u00f3n para evitar la vinculaci\u00f3n del controlador entre pci_stop_bus_device() y pci_remove_bus_device(). En el caso de Dennis, parece que la eliminaci\u00f3n de la jerarqu\u00eda por parte de pciehp compite con la vinculaci\u00f3n del controlador por parte de pci_bus_add_devices(). pciehp est\u00e1 vinculado al puerto descendente despu\u00e9s 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 \u00e9l dan como resultado un use-after-free. Se podr\u00eda concluir que es necesario evitar la vinculaci\u00f3n del controlador despu\u00e9s 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 \u00fanicamente en el orden correcto de la desvinculaci\u00f3n del controlador frente a la destrucci\u00f3n de pci_bus ciertamente no es programaci\u00f3n 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\u00f1alizaci\u00f3n con IRQ 156 pcieport 0000:00:07.0: pciehp: Ranura n.\u00ba 12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, cre\u00f3 la ranura f\u00edsica 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\u00f3n general, probablemente para una direcci\u00f3n no can\u00f3nica 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\u00f3n pci pciehp_remove servicio de eliminaci\u00f3n de puerto pcie dispositivo de liberaci\u00f3n 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\u00f3n_controlador_interno_bus_
    }
  ],
  "metrics": {},
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/20502f0b3f3acd6bee300257556c27a867f80c8b",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/41bbb1eb996be1435815aa1fbcc9ffc45b84cc12",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/50473dd3b2a08601a078f852ea05572de9b1f86c",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/69d2ceac11acf8579d58d55c9c5b65fb658f916e",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/c7acef99642b763ba585f4a43af999fcdbcc3dc4",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/c8266ab8e7ccd1d1f5a9c8b29eb2020175048134",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/d0ddd2c92b75a19a37c887154223372b600fed37",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/da6e6ff1f6c57f16e07af955e0e997fc90dd1e75",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/e5d5c04aac71bf1476dc44b56f2206a4c2facca8",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ]
}