CVE-2026-98474: s390/pci: Fix missing device lock in zpci_report_status()
In the Linux kernel, the following vulnerability has been resolved:
s390/pci: Fix missing device lock in zpcireportstatus()
When pdev is non-NULL, zpcireportstatus() accesses the device's driver. To get a consistent state matching the recovery, the device lock needs to be held. Do so by expanding the existing device lock critical section.
The lock only needs to be held when the pdev is non-NULL, so extract the pdev-specific reporting into a helper function which also adds a lockdep assertion to detect calls without the device lock held.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
Expand the existing device lock critical section so the device lock is held whenever pdev is non-NULL during zpci_report_status(); keep pdev-specific reporting in a helper with a lockdep assertion that detects calls without the device lock held.
Event History
Frequently Asked Questions
Which systems are relevant to this issue?
The issue is in the Linux kernel s390 PCI code path, specifically status reporting when a non-NULL PCI device is present. Systems that do not use this code path are not indicated as affected by the available information.
What condition triggers the unsafe access?
The condition occurs when zpci_report_status() handles a non-NULL pdev and accesses that device's driver without holding the device lock. The fix expands the existing lock-protected critical section so the device state remains consistent with recovery processing.
How can maintainers detect similar incorrect call paths?
The revised pdev-specific reporting helper includes a lockdep assertion. This is intended to detect calls made without the required device lock being held.