CVE-2025-39958

In the Linux kernel, the following vulnerability has been resolved:

iommu/s390: Make attach succeed when the device was surprise removed

When a PCI device is removed with surprise hotplug, there may still be

attempts to attach the device to the default domain as part of tear down

via (__iommu_release_dma_ownership()), or because the removal happens

during probe (__iommu_probe_device()). In both cases zpci_register_ioat()

fails with a cc value indicating that the device handle is invalid. This

is because the device is no longer part of the instance as far as the

hypervisor is concerned.

Currently this leads to an error return and s390_iommu_attach_device()

fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()

because attaching to the default domain must never fail.

With the device fenced by the hypervisor no DMAs to or from memory are

possible and the IOMMU translations have no effect. Proceed as if the

registration was successful and let the hotplug event handling clean up

the device.

This is similar to how devices in the error state are handled since

commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device

is in error state") except that for removal the domain will not be

registered later. This approach was also previously discussed at the

link.

Handle both cases, error state and removal, in a helper which checks if

the error needs to be propagated or ignored. Avoid magic number

condition codes by using the pre-existing, but never used, defines for

PCI load/store condition codes and rename them to reflect that they

apply to all PCI instructions.