CVE-2025-39958

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

arch/s390/include/asm/pci_insn.h
drivers/iommu/s390-iommu.c

What this is

S390 ARCHITECTUREMAINTAINERS section matched on arch/s390/ · linux-s390@vger.kernel.org · Supported

Check it on the machine

grep -w CONFIG_S390_IOMMU /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code in 1 release. It does build it in 3 releases, so the answer depends on which release the machine runs.

• bookwormn
• trixieYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt/arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64
• forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/arm64, arm64/arm64-16k, arm64/cloud-arm64, arm64/rt-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64

n

not enabled on any flavour - this release does not build the code

Y

built in where it is built at all; some flavours do not build it

Build switch

CONFIG_S390_IOMMU

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2025-10-09 (12 months ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.14%, higher than 3.3% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

unimportantsource

Subsystem

arch/s390

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
6.2	6.16.9	359613f2fa00
6.2	6.17	9ffaf5229055