CVE-2026-97593: iommu/s390: Fix NULL dereference in iova_to_phys() with ZPCI_TABLE_TYPE_RFX
In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Fix NULL dereference in iovatophys() with ZPCITABLETYPERFX
When using a 5-level translation table via ZPCITABLETYPERFX getrsofromiova() returns NULL when the region-first entry is invalid. Yet in getrtofromiova() the region-second origin rso is not checked to be non-NULL before accessing rso[rsx] leading to a NULL pointer dereference instead of a NULL return when iovatophys() is called on a unmapped IOVA. Fix this by adding the missing NULL check.
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
Add a NULL check in get_rto_from_iova() to verify the region-second origin (rso) is non-NULL before accessing rso[rsx], so iova_to_phys() returns NULL for an unmapped IOVA instead of dereferencing a NULL pointer.
Event History
Frequently Asked Questions
Which systems are affected by this issue?
The issue affects Linux kernel systems using the s390 IOMMU implementation with a 5-level translation table configured through ZPCI_TABLE_TYPE_RFX. The problematic path is reached when iova_to_phys() is called for an unmapped IOVA whose region-first entry is invalid.
What happens when the vulnerable code is triggered?
Instead of returning NULL for the unmapped IOVA, the kernel dereferences a NULL region-second origin pointer. This results in a NULL pointer dereference.
What is the immediate mitigation if an updated kernel cannot be deployed?
Avoid calling iova_to_phys() on unmapped IOVAs when using ZPCI_TABLE_TYPE_RFX 5-level translation tables. The provided data does not specify another workaround.