一、漏洞信息
漏洞编号：CVE-2024-53194
漏洞归属组件：kernel
漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.4.0,6.6.0
CVSS V3.0分值：
BaseScore：0.0 None
Vector：CVSS：3.0/
漏洞简述：
In the Linux kernel, the following vulnerability has been resolved:PCI: Fix use-after-free of slot->bus on hot removeDennis reports a boot crash on recent Lenovo laptops with a USB4 dock.Since commit 0fc70886569c ( thunderbolt: Reset USB4 v2 host router ) andcommit 59a54c5f3dbd ( thunderbolt: Reset topology created by the bootfirmware ), USB4 v2 and v1 Host Routers are reset on probe of thethunderbolt driver.The reset clears the Presence Detect State and Data Link Layer Link Activebits at the USB4 Host Router s Root Port and thus causes hot removal of thedock.The crash occurs when pciehp is unbound from one of the dock s DownstreamPorts: pciehp creates a pci_slot on bind and destroys it on unbind. Thepci_slot contains a pointer to the pci_bus below the Downstream Port, buta reference on that pci_bus is never acquired. The pci_bus is destroyedbefore the pci_slot, so a use-after-free ensues when pci_slot_release()accesses slot->bus.In principle this should not happen because pci_stop_bus_device() unbindspciehp (and therefore destroys the pci_slot) before the pci_bus isdestroyed by pci_remove_bus_device().However the stacktrace provided by Dennis shows that pciehp is unbound frompci_remove_bus_device() instead of pci_stop_bus_device(). To understandthe significance of this, one needs to know that the PCI core uses a twostep process to remove a portion of the hierarchy: It first unbinds alldrivers in the sub-hierarchy in pci_stop_bus_device() and then actuallyremoves the devices in pci_remove_bus_device(). There is no precaution toprevent driver binding in-between pci_stop_bus_device() andpci_remove_bus_device().In Dennis case, it seems removal of the hierarchy by pciehp races withdriver binding by pci_bus_add_devices(). pciehp is bound to theDownstream Port after pci_stop_bus_device() has run, so it is unbound bypci_remove_bus_device() instead of pci_stop_bus_device(). Because thepci_bus has already been destroyed at that point, accesses to it result ina use-after-free.One might conclude that driver binding needs to be prevented afterpci_stop_bus_device() has run. However it seems risky that pci_slot pointsto pci_bus without holding a reference. Solely relying on correct orderingof driver unbind versus pci_bus destruction is certainly not defensiveprogramming.If pci_slot has a need to access data in pci_bus, it ought to acquire areference. Amend pci_create_slot() accordingly. Dennis reports that thecrash is not reproducible with this change.Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist
漏洞公开时间：2024-12-27 22:15:27
漏洞创建时间：2024-12-27 22:47:08
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-53194

漏洞分析指导链接：
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：

二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:PCI: Fix use-after-free of slot->bus on hot removeDennis reports a boot crash on recent Lenovo laptops with a USB4 dock.Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") andcommit 59a54c5f3dbd ("thunderbolt: Reset topology created by the bootfirmware"), USB4 v2 and v1 Host Routers are reset on probe of thethunderbolt driver.The reset clears the Presence Detect State and Data Link Layer Link Activebits at the USB4 Host Router's Root Port and thus causes hot removal of thedock.The crash occurs when pciehp is unbound from one of the dock's DownstreamPorts: pciehp creates a pci_slot on bind and destroys it on unbind. Thepci_slot contains a pointer to the pci_bus below the Downstream Port, buta reference on that pci_bus is never acquired. The pci_bus is destroyedbefore the pci_slot, so a use-after-free ensues when pci_slot_release()accesses slot->bus.In principle this should not happen because pci_stop_bus_device() unbindspciehp (and therefore destroys the pci_slot) before the pci_bus isdestroyed by pci_remove_bus_device().However the stacktrace provided by Dennis shows that pciehp is unbound frompci_remove_bus_device() instead of pci_stop_bus_device(). To understandthe significance of this, one needs to know that the PCI core uses a twostep process to remove a portion of the hierarchy: It first unbinds alldrivers in the sub-hierarchy in pci_stop_bus_device() and then actuallyremoves the devices in pci_remove_bus_device(). There is no precaution toprevent driver binding in-between pci_stop_bus_device() andpci_remove_bus_device().In Dennis' case, it seems removal of the hierarchy by pciehp races withdriver binding by pci_bus_add_devices(). pciehp is bound to theDownstream Port after pci_stop_bus_device() has run, so it is unbound bypci_remove_bus_device() instead of pci_stop_bus_device(). Because thepci_bus has already been destroyed at that point, accesses to it result ina use-after-free.One might conclude that driver binding needs to be prevented afterpci_stop_bus_device() has run. However it seems risky that pci_slot pointsto pci_bus without holding a reference. Solely relying on correct orderingof driver unbind versus pci_bus destruction is certainly not defensiveprogramming.If pci_slot has a need to access data in pci_bus, it ought to acquire areference. Amend pci_create_slot() accordingly. Dennis reports that thecrash is not reproducible with this change.Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_istThe Linux kernel CVE team has assigned CVE-2024-53194 to this issue.
openEuler评分：
5.5
Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
受影响版本排查(受影响/不受影响)：
1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP1(5.10.0):受影响
3.openEuler-22.03-LTS-SP3(5.10.0):受影响
4.openEuler-22.03-LTS-SP4(5.10.0):受影响
5.openEuler-24.03-LTS(6.6.0):受影响
6.openEuler-24.03-LTS-SP1(6.6.0):受影响
7.master:不受影响
8.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP1(5.10.0):否
3.openEuler-22.03-LTS-SP3(5.10.0):否
4.master:否
5.openEuler-24.03-LTS(6.6.0):否
6.openEuler-24.03-LTS-Next(6.6.0):否
7.openEuler-22.03-LTS-SP4(5.10.0):否
8.openEuler-24.03-LTS-SP1(6.6.0):否

原因说明：
1.openEuler-20.03-LTS-SP4(4.19.90):正常修复
2.openEuler-22.03-LTS-SP1(5.10.0):正常修复
3.openEuler-22.03-LTS-SP3(5.10.0):正常修复
4.openEuler-22.03-LTS-SP4(5.10.0):正常修复
5.openEuler-24.03-LTS(6.6.0):正常修复
6.openEuler-24.03-LTS-SP1(6.6.0):正常修复
7.master:不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发

三、漏洞修复
安全公告链接：https://www.openeuler.org/zh/security/safety-bulletin/detail/?id=openEuler-SA-2025-1079