KernelScan.io

HIGH Introduced in 5.8

pci PerFuncSlot Leak

CVE-2026-89795

CVSS 8.4 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H

KernelScan AI5.0MEDIUM

01

In the Linux kernel, the following vulnerability has been resolved: PCI: Allow per function PCI slots to fix slot reset on s390 On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions. Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system. Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface. When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release(). Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.

02

Engine v0.6.0

Risk summary

On s390 systems with multifunction PCI devices, the PCI slot subsystem assigns a shared slot object to all functions of a device. This causes the wrong PCI function to be reset when a hotplug slot reset is requested, and leaks memory because per-function slot objects are never freed. An attacker with root-level access to the PCI hotplug interface could disrupt device availability or exhaust memory through repeated hotplug operations.

Affecteddrivers/pci/slot.c (PCI subsystem)

Vulnerability analysis

When a multifunction PCI device is registered on s390, the PCI slot subsystem assigns the same slot object to all functions. Because the s390 hypervisor operates at per-function granularity, requesting a slot reset for one function instead resets a different function. Additionally, slot objects created for individual functions are never freed during cleanup, causing a memory leak that grows with each hotplug cycle. The fix gives each function its own slot object and ensures devices are correctly matched to their slots when they are assigned and released. This issue is only reachable on s390 hardware with multifunction PCI devices exposed through a shared PCI domain, and triggering the slot reset path requires privileged access to the PCI hotplug interface.

03

BranchIntroducedFixed inPatch commit
6.125.86.12.1120d1a7d67f456
6.185.86.18.522050d900f9ad
6.65.86.6.160b4a80e9e639c
7.25.87.2.5ecdcceed4d37
mainline5.87.3dcc5bec09e23
cip/6.125.86.12.112-cip330d1a7d67f456

04

State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.

CIP treeState
cip/6.12Fixed in 6.12.112-cip33
cip/6.1Affected — no CIP fix yet (latest 6.1.189-cip61)
cip/6.1-rtAffected — no CIP fix yet (latest 6.1.189-cip61-rt32)
cip/5.10Affected — no CIP fix yet (latest 5.10.271-cip78)
cip/5.10-rtAffected — no CIP fix yet (latest 5.10.268-cip77-rt34)