Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal privileged access on s390 host
-
DeliveryTrigger surprise PCI hotplug removal
-
ExploitConcurrent default-domain attach fails with invalid handle
-
ExecutionWARN_ON fires in nofail path
-
ImpactKernel log corruption or panic_on_warn crash
Vulnerability Assessment
| Exploitation Conditions | Requires the s390 (IBM Z) architecture with the s390 IOMMU driver, a PCI device undergoing surprise hotplug removal (or removal occurring mid-probe), and a concurrent attempt to attach the device to its default IOMMU domain via __iommu_release_dma_ownership() or __iommu_probe_device(). The condition is reached only during this device-lifecycle teardown race, not via arbitrary attacker input. Limiting factors: affected only on s390 (not x86/arm), only on 6.17-rc development kernels, requires local privileged participation in device/hotplug management, and the WARN_ON is non-fatal unless panic_on_warn is configured - substantially narrowing realistic impact below the raw CVSS score. |
| Impact | The input CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) is the NVD/kernel-CNA auto-assigned 'full impact, local, low-privilege' template applied broadly to Linux kernel fixes, and it materially overstates this specific issue. The actual defect is a robustness bug: during surprise PCI hotplug removal on s390, zpci_register_ioat() returns an invalid-device-handle condition code, s390_iommu_attach_device() propagates the error, and the WARN_ON() in __iommu_group_set_domain_nofail() fires because attaching the default domain must never fail. That is an availability/reliability symptom (kernel warning, potential instability or panic only if panic_on_warn is set), not a confidentiality or integrity compromise - so the input's C:H/I:H claims are not supported by the description. No EPSS score, no CISA KEV listing, and no POC were provided; exploitation status is therefore 'no public exploit identified at time of analysis'. There is no attacker-driven exploitation path in the usual sense: the condition arises from legitimate device teardown/hotplug on IBM Z mainframe hardware, not from a crafted remote or local payload. Net assessment: this is a low-real-risk hardening fix despite the HIGH auto-CVSS, relevant only to s390 operators running 6.17-rc kernels; prioritize via normal stable-kernel update cadence, not as an urgent security response. |
| Exploit ScenarioDerived | On an IBM Z (s390) system running an affected 6.17-rc kernel, an operator or orchestration layer performs a surprise PCI hotplug removal of a device while the kernel is concurrently tearing down or probing it; the re-attach to the default domain fails with an invalid handle and trips WARN_ON(), producing kernel log noise and, under panic_on_warn, a crash. No public exploit code is available and the trigger is a device-lifecycle race rather than an attacker-supplied input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Linux kernel s390 IOMMU handling can trigger a non-fatal WARN_ON during surprise PCI hotplug removal when the kernel tries to attach the removed device to its default IOMMU domain and zpci_register_ioat() reports an invalid device handle. The issue affects IBM Z/s390 systems running Linux 6.17-rc1 through 6.17-rc6 and requires local privileged participation in device/hotplug management during a narrow teardown or probe race; realistic impact is availability-only and non-fatal unless panic_on_warn is configured. No public exploit identified at time of analysis, and vendor stable patches are available.
RemediationAI
Patch available per vendor advisory; apply the stable commits at https://git.kernel.org/stable/c/359613f2fa009587154511e4842e8ab9532edd15 and https://git.kernel.org/stable/c/9ffaf5229055fcfbb3b3d6f1c7e58d63715c3f73, or update to a kernel build that includes them. Because exploitation requires local privileged control over PCI hotplug/device lifecycle on s390, restrict device-management privileges to trusted administrators as a compensating control while patching. Avoid unplanned surprise removal of PCI devices on affected s390 hosts where operationally feasible; this reduces exposure but does not replace the fix. Disabling panic_on_warn would prevent the non-fatal WARN_ON from rebooting a host, but it masks the symptom, weakens diagnostics, and is not a remediation.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is in the Linux kernel's s390 IOMMU support for PCI devices. On IBM Z, zpci_register_ioat() registers the device's DMA address translations with the hypervisor; when a PCI device is surprise-removed, the hypervisor may already consider the device handle invalid, so registration returns a condition code indicating an invalid handle. The kernel nevertheless must not fail an attach to the default domain during __iommu_release_dma_ownership() or __iommu_probe_device(), because __iommu_group_set_domain_nofail() contains a WARN_ON() for that impossible condition. The fix mirrors commit 59bbf596791b for devices in error state, adding a helper that decides whether PCI condition-code errors should be propagated or ignored and renaming condition-code defines. No CWE is assigned; the root cause is improper handling of a device-removal condition code during IOMMU attach. CPE data identifies Linux kernel 6.17 rc1 through rc6; the assessed vector is AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L, and the CVE's 7.8 vector appears to be a generic local full-impact template that overstates this s390-specific, non-fatal lifecycle issue.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Sources disagree (Low–High)AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local s390-only path requiring a surprise-removal/attach race (AV:L, AC:H, PR:L); only availability is affected via a non-fatal WARN_ON, so C:N/I:N/A:L.
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorNVD
DescriptionNVD
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.
Executive ViewAI
A high-severity defect in the Linux kernel's s390 IOMMU code affects IBM Z (s390x) systems running Linux 6.17-rc1 through 6.17-rc6, where an unexpected PCI device hotplug removal can trigger a kernel warning during IOMMU domain teardown. Impact is confined to availability and is non-fatal in normal configurations, escalating to a system panic only on hosts where panic_on_warn is enabled; exploitation requires local privileged involvement in device or hotplug management during a narrow race window, and no public exploit code has been identified. Leadership should care because the exposure is limited to a small population of IBM Z hosts on release-candidate kernels, but any host running with panic_on_warn enabled could suffer an unintended outage during routine hardware servicing.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
GitHub PoC
Exploit-DB