CVE-2025-39958

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Make attach succeed when the device was surprise removed<br /> <br /> When a PCI device is removed with surprise hotplug, there may still be<br /> attempts to attach the device to the default domain as part of tear down<br /> via (__iommu_release_dma_ownership()), or because the removal happens<br /> during probe (__iommu_probe_device()). In both cases zpci_register_ioat()<br /> fails with a cc value indicating that the device handle is invalid. This<br /> is because the device is no longer part of the instance as far as the<br /> hypervisor is concerned.<br /> <br /> Currently this leads to an error return and s390_iommu_attach_device()<br /> fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()<br /> because attaching to the default domain must never fail.<br /> <br /> With the device fenced by the hypervisor no DMAs to or from memory are<br /> possible and the IOMMU translations have no effect. Proceed as if the<br /> registration was successful and let the hotplug event handling clean up<br /> the device.<br /> <br /> This is similar to how devices in the error state are handled since<br /> commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device<br /> is in error state") except that for removal the domain will not be<br /> registered later. This approach was also previously discussed at the<br /> link.<br /> <br /> Handle both cases, error state and removal, in a helper which checks if<br /> the error needs to be propagated or ignored. Avoid magic number<br /> condition codes by using the pre-existing, but never used, defines for<br /> PCI load/store condition codes and rename them to reflect that they<br /> apply to all PCI instructions.