CVE-2026-89795 in Linux
Summary
by MITRE • 09/16/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability described involves a logical flaw in the Linux kernel's PCI subsystem, specifically within the handling of PCI hotplug slots on s390 architectures that utilize machine-level hypervisors. The core issue stems from an incorrect assumption about device topology where multifunction PCI devices are assigned to shared pci_slot objects rather than individual function-specific slot structures. This architectural mismatch arises because modern s390 configurations expose the full topology of multifunction PCI devices by grouping them into a shared PCI domain, whereas previous implementations only exposed virtual functions as distinct domains. Consequently, when an administrator or automated system attempts to reset a specific PCI function via the hotplug driver's reset_slot interface, the kernel incorrectly targets the entire shared slot rather than the intended individual function. This results in operational failures where the wrong device is reset, potentially causing service disruption for unrelated devices sharing that physical slot on the host side of the hypervisor passthrough mechanism.
From a technical perspective, this defect represents an improper assignment of resources and state management errors within the kernel's PCI abstraction layer. The pci_create_slot function historically grouped multifunction devices under a single slot identifier to simplify legacy handling. However, with the introduction of support for exposing multifunction topologies in commit 44510d6fa0c0, this grouping logic became obsolete and incorrect for s390 environments that require per-function granularity due to hypervisor pass-through constraints. The reset_slot wrapper function zpci_hot_reset_device operates at the PCI function level, but because it interacts with a shared pci_slot object, it cannot distinguish which specific function within the multifunction device should be targeted. This leads to incorrect hardware state transitions and violates the principle of least privilege by affecting devices that were not intended for reset operations.
The operational impact extends beyond mere functional errors in device resetting. The code path associated with this flaw also introduces a memory leak vulnerability. When the system attempts to manage these per-function slots, it allocates new pci_slot objects but fails to properly deallocate them during cleanup via pci_slot_release. Over time, particularly in environments with frequent hotplug operations or dynamic device attachment and detachment scenarios such as cloud infrastructure on s390 mainframes, this memory leak can lead to resource exhaustion. This degradation of system resources may eventually cause instability, performance bottlenecks, or kernel panics due to insufficient memory availability for critical subsystems.
This vulnerability aligns with CWE-416, Use After Free, in the context where improper handling leads to inconsistent state, and more accurately with CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, if the incorrect reset exposes sensitive data from a previously active device on another function within the same multifunction unit. In terms of MITRE ATT&CK, this could be leveraged in techniques related to T1499 Endpoint Denial of Service or T1529 System Shutdown/Reboot if an attacker with access to hotplug interfaces can trigger resets on critical system components by exploiting the misidentification of target functions. The flaw essentially allows for unintended side effects through standard administrative APIs, undermining the reliability of hardware management tools.
Mitigation strategies primarily involve applying kernel patches that introduce a flag within the struct pci_slot structure to explicitly allow per-function PCI slots for devices managed through hypervisors. This change ensures that each individual PCI function is treated as an independent entity with its own slot object during hotplug operations, thereby correcting the reset target logic. Additionally, developers must ensure proper memory management by updating pci_slot_release to correctly free these newly allocated structures, eliminating the associated memory leak. System administrators should apply updated kernel versions that include this fix and verify that hypervisor configurations are aligned with the new per-function slot handling expectations. Regular auditing of hotplug operations on s390 systems is recommended to detect any anomalies in device state transitions until patches are fully deployed across all affected infrastructure nodes.