CVE-2023-53123
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2023-53123
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2023-53123.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2023-53123
- Downstream
- Related
- Published
- 2025-05-02T15:55:59Z
- Modified
- 2025-10-16T15:46:38.308994Z
- Summary
- PCI: s390: Fix use-after-free of PCI resources with per-function hotplug
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
PCI: s390: Fix use-after-free of PCI resources with per-function hotplug
On s390 PCI functions may be hotplugged individually even when they belong to a multi-function device. In particular on an SR-IOV device VFs may be removed and later re-added.
In commit a50297cf8235 ("s390/pci: separate zbus creation from scanning") it was missed however that struct pcibus and struct zpcibus's resource list retained a reference to the PCI functions MMIO resources even though those resources are released and freed on hot-unplug. These stale resources may subsequently be claimed when the PCI function re-appears resulting in use-after-free.
One idea of fixing this use-after-free in s390 specific code that was investigated was to simply keep resources around from the moment a PCI function first appeared until the whole virtual PCI bus created for a multi-function device disappears. The problem with this however is that due to the requirement of artificial MMIO addreesses (address cookies) extra logic is then needed to keep the address cookies compatible on re-plug. At the same time the MMIO resources semantically belong to the PCI function so tying their lifecycle to the function seems more logical.
Instead a simpler approach is to remove the resources of an individually hot-unplugged PCI function from the PCI bus's resource list while keeping the resources of other PCI functions on the PCI bus untouched.
This is done by introducing pcibusremoveresource() to remove an individual resource. Similarly the resource also needs to be removed from the struct zpcibus's resource list. It turns out however, that there is really no need to add the MMIO resources to the struct zpcibus's resource list at all and instead we can simply use the zpcibar_struct's resource pointer directly.
- References
-
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- https://git.kernel.org/stable/c/437bb839e36cc9f35adc6d2a2bf113b7a0fc9985
- https://git.kernel.org/stable/c/a2410d0c3d2d714ed968a135dfcbed6aa3ff7027
- https://git.kernel.org/stable/c/ab909509850b27fd39b8ba99e44cda39dbc3858c
- https://git.kernel.org/stable/c/b99ebf4b62774e690e73a551cf5fbf6f219bdd96
Affected packages
Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Affected ranges
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduceda50297cf8235b062bcdeaa8b1dad58e69d3e1b43Fixed437bb839e36cc9f35adc6d2a2bf113b7a0fc9985
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduceda50297cf8235b062bcdeaa8b1dad58e69d3e1b43Fixeda2410d0c3d2d714ed968a135dfcbed6aa3ff7027
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduceda50297cf8235b062bcdeaa8b1dad58e69d3e1b43Fixedb99ebf4b62774e690e73a551cf5fbf6f219bdd96
- Type
- GIT
- Repo
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
- Events
-
Introduceda50297cf8235b062bcdeaa8b1dad58e69d3e1b43Fixedab909509850b27fd39b8ba99e44cda39dbc3858c