GHSA-77Q7-746M-WX38
Vulnerability from github – Published: 2026-09-16 12:30 – Updated: 2026-09-16 15:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-89795"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-16T11:16:44Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Allow per function PCI slots to fix slot reset on s390\n\nOn s390 systems, which use a machine level hypervisor, PCI devices are\nalways accessed through a form of PCI pass-through which fundamentally\noperates on a per PCI function granularity. This is also reflected in the\ns390 PCI hotplug driver which creates hotplug slots for individual PCI\nfunctions. Its reset_slot() function, which is a wrapper for\nzpci_hot_reset_device(), thus also resets individual functions.\n\nCurrently, the pci_create_slot() assigns the same pci_slot object to\nmultifunction devices. This approach worked fine on s390 systems that only\nexposed virtual functions as individual PCI domains to the operating\nsystem. Since commit 44510d6fa0c0 (\"s390/pci: Handling multifunctions\")\ns390 supports exposing the topology of multifunction PCI devices by\ngrouping them in a shared PCI domain. This creates a problem when resetting\na function through the hotplug driver\u0027s slot_reset() interface.\n\nWhen attempting to reset a function through the hotplug driver, the shared\nslot assignment causes the wrong function to be reset instead of the\nintended one. It also leaks memory as we do create a pci_slot object for\nthe function, but don\u0027t correctly free it in pci_slot_release().\n\nAdd a flag for struct pci_slot to allow per function PCI slots for\nfunctions managed through a hypervisor, which exposes individual PCI\nfunctions while retaining the topology. Since we can use all 8 bits for\nslot \u0027number\u0027 (for ARI devices), change slot \u0027number\u0027 u16 to account for\nspecial values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.",
"id": "GHSA-77q7-746m-wx38",
"modified": "2026-09-16T15:30:57Z",
"published": "2026-09-16T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89795"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2050d900f9adbd6d6f38d30e182bcd9ad3108467"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dcc5bec09e23bbc4f9de055a11fce9937244f2c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ecdcceed4d377b02d4ea036b65f83f962c38ede7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.