CVE-2025-39958
published 2025-10-09CVE-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…
PriorityP338high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.13%
3.3th percentile
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.
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.16.9-1 (forky) | linux 6.16.9-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 59bbf596791b89c7f88fdcac29dfc39c1221d25d < 359613f2fa009587154511e4842e8ab9532edd15 | 359613f2fa009587154511e4842e8ab9532edd15 |
| linux | linux | >= 59bbf596791b89c7f88fdcac29dfc39c1221d25d < 9ffaf5229055fcfbb3b3d6f1c7e58d63715c3f73 | 9ffaf5229055fcfbb3b3d6f1c7e58d63715c3f73 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.16.9-1 | 6.16.9-1 |
| linux | linux_kernel | >= 6.2 < 6.16.9 | 6.16.9 |
| msrc | azl3_kernel_6.6.96.2-2_on_azure_linux_3.0 | — | — |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8LOW
vendor_redhat7.8HIGH
vendor_msrc4.0MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
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 de
osv·2025-10-09·CVSS 7.8
CVE-2025-39958 [HIGH] 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 de
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 th
GHSA
GHSA-p5vh-p63c-cg4v: In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Make attach succeed when the device was surprise removed
When a PCI
ghsa_unreviewed·2025-10-09
CVE-2025-39958 [HIGH] GHSA-p5vh-p63c-cg4v: In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Make attach succeed when the device was surprise removed
When a PCI
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.
Wit
Microsoft
iommu/s390: Make attach succeed when the device was surprise removed
vendor_msrc·2025-10-14·CVSS 4.0
CVE-2025-39958 [HIGH] iommu/s390: Make attach succeed when the device was surprise removed
iommu/s390: Make attach succeed when the device was surprise removed
FAQ: Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?
One of the main benefits to our customers who choose to use the Azure Linux distro is the commitment to keep it up to date with the most recent and most secure versions of the open source libraries with which the distro is composed. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. See this blog post for more information. If impact to additional products is identified, we will update the CVE to reflect this.
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Red Hat
kernel: iommu/s390: Make attach succeed when the device was surprise removed
vendor_redhat·2025-10-09·CVSS 7.8
CVE-2025-39958 [HIGH] kernel: iommu/s390: Make attach succeed when the device was surprise removed
kernel: iommu/s390: Make attach succeed when the device was surprise removed
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_do
Debian
CVE-2025-39958: linux - In the Linux kernel, the following vulnerability has been resolved: iommu/s390:...
vendor_debian·2025·CVSS 7.8
CVE-2025-39958 [HIGH] CVE-2025-39958: linux - In the Linux kernel, the following vulnerability has been resolved: iommu/s390:...
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 th
No detection rules found.
No public exploits indexed.
Bleepingcomputer
Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
blogs_bleepingcomputer·2025-10-14·CVSS 7.8
[HIGH] Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
## Microsoft October 2025 Patch Tuesday fixes 6 zero-days, 172 flaws
## Lawrence Abrams
80 Elevation of Privilege Vulnerabilities
11 Security Feature Bypass Vulnerabilities
31 Remote Code Execution Vulnerabilities
28 Information Disclosure Vulnerabilities
11 Denial of Service Vulnerabilities
10 Spoofing Vulnerabilities
When BleepingComputer reports on the Patch Tuesday security updates, we only count those released today by Microsoft. Therefore, the number of flaws does not include those fixed in Azure, Mariner, Microsoft Edge, and other vulnerabilities earlier this month.
Notably, Windows 10 reaches the end of support today , with this being the last Patch Tuesday where Microsoft provides free security updates to the venerable operating system.
To continue receiving security upd
Bugzilla
CVE-2025-39958 kernel: iommu/s390: Make attach succeed when the device was surprise removed
bugzilla·2025-10-09·CVSS 7.8
CVE-2025-39958 [HIGH] CVE-2025-39958 kernel: iommu/s390: Make attach succeed when the device was surprise removed
CVE-2025-39958 kernel: iommu/s390: Make attach succeed when the device was surprise removed
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 __
2025-10-09
Published