Google: sys-kernel/lakitu-kernel-6_1: security update to 18244.291.3

high Tenable Self-Hosted Container Security Plugin ID 450813

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

- In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus
on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit
0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset
topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt
driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host
Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from
one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The
pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is
never acquired. The pci_bus is destroyed before 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()
unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by
pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from
pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one
needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first
unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in
pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device()
and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with
driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after
pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of
pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result
in a use-after-free. One might conclude that driver binding needs to be prevented after
pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a
reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not
defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference.
Amend pci_create_slot() accordingly. Dennis reports that the crash 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
(CVE-2024-53194)

Solution

Update the sys-kernel/lakitu-kernel-6_1 library and its related packages to version 18244.291.3 or later.

Plugin Details

Severity: High

ID: 450813

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Medium

Score: 4.9

Percentile: 57.12

Vendor

Vendor Severity: HIGH

CVSS v2

Risk Factor: Medium

Base Score: 6.8

Temporal Score: 5

Vector: CVSS2#AV:L/AC:L/Au:S/C:C/I:C/A:C

CVSS Score Source: CVE-2024-53194

CVSS v3

Risk Factor: High

Base Score: 7.8

Temporal Score: 6.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 12/27/2024

Reference Information

CVE: CVE-2024-53194

Detections

Analytics