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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
CVSS Score: 8.4
AV:L - The flaw is reached from local PCI reset paths (sysfs device reset, VFIO_DEVICE_RESET, and vfio_pci_core_enable()) that call pci_try_reset_function() -> pci_dev_reset_slot_function() -> s390 reset_slot()/zpci_hot_reset_device(); there is no network or adjacent-radio path.
AC:L - On s390 multifunction domains pci_create_slot() matches PCI_SLOT(devfn) against a full 8-bit slot number, so siblings/VFs are assigned the wrong pci_slot and a reset deterministically invokes the other function's hotplug reset_slot() with no race or attacker-uncontrollable layout.
PR:L - vfio_pci_core_enable() and VFIO_DEVICE_RESET call pci_try_reset_function() with no capable() check on the IOMMU path; IBM Z/LinuxONE SR-IOV VF passthrough routinely grants that VFIO fd to an unprivileged qemu/tenant user rather than init-namespace root.
UI:N - The attacker opens the assigned VFIO device or issues VFIO_DEVICE_RESET themselves; prior admin binding of the zPCI function to vfio-pci is deployment configuration, not victim interaction.
S:C - Function reset uses the wrongly shared pci_slot and issues zpci_hot_reset_device() on a sibling/PF outside the caller's VFIO device set, bypassing VFIO's slot-wide membership check and crossing zPCI per-function isolation into host or other-tenant devices.
C:N - This is a wrong-function hardware reset plus a pci_slot lifetime leak; it does not perform an out-of-bounds read, use-after-free, or other disclosure of kernel or other users' memory.
I:H - zpci_hot_reset_device() disable/re-enable of the unintended function wipes that function's hardware state behind its owner's driver, destroying in-flight I/O and device configuration on a host PF or another tenant's NIC/storage function.
A:H - Surprise reset of an in-use PF or sibling denies that device and all VFs behind it, and can oops the bound host driver which continues MMIO against a freshly reset zPCI function, causing host kernel availability loss.
| Attack Vector |
Local |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
None |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The flaw is reached from local PCI reset paths (sysfs device reset, VFIO_DEVICE_RESET, and vfio_pci_core_enable()) that call pci_try_reset_function() -> pci_dev_reset_slot_function() -> s390 reset_slot()/zpci_hot_reset_device(); there is no network or adjacent-radio path.
AC:L - On s390 multifunction domains pci_create_slot() matches PCI_SLOT(devfn) against a full 8-bit slot number, so siblings/VFs are assigned the wrong pci_slot and a reset deterministically invokes the other function's hotplug reset_slot() with no race or attacker-uncontrollable layout.
PR:L - vfio_pci_core_enable() and VFIO_DEVICE_RESET call pci_try_reset_function() with no capable() check on the IOMMU path; IBM Z/LinuxONE SR-IOV VF passthrough routinely grants that VFIO fd to an unprivileged qemu/tenant user rather than init-namespace root.
UI:N - The attacker opens the assigned VFIO device or issues VFIO_DEVICE_RESET themselves; prior admin binding of the zPCI function to vfio-pci is deployment configuration, not victim interaction.
S:C - Function reset uses the wrongly shared pci_slot and issues zpci_hot_reset_device() on a sibling/PF outside the caller's VFIO device set, bypassing VFIO's slot-wide membership check and crossing zPCI per-function isolation into host or other-tenant devices.
C:N - This is a wrong-function hardware reset plus a pci_slot lifetime leak; it does not perform an out-of-bounds read, use-after-free, or other disclosure of kernel or other users' memory.
I:H - zpci_hot_reset_device() disable/re-enable of the unintended function wipes that function's hardware state behind its owner's driver, destroying in-flight I/O and device configuration on a host PF or another tenant's NIC/storage function.
A:H - Surprise reset of an in-use PF or sibling denies that device and all VFs behind it, and can oops the bound host driver which continues MMIO against a freshly reset zPCI function, causing host kernel availability loss.
CVSS 3.1