Evidence used
- No CISA KEV confirmation is currently recorded.
- Exploitation requires an existing local or physical foothold with privileges.
- EPSS is 0.14% for the current model date.
BlackTreeCVE IntelligenceLinux · Linux
High technical severity; prioritise exposed affected systems while verifying vendor guidance. Verified remediation exists for at least one product or source, but 22 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Verified remediation exists for at least one product or source, but 22 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Debian, ubuntu findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
BlackTree has verified remediation for at least one product or source, but the relevant distribution still reports no fixed package for 22 affected package states shown here. Treat those rows as affected with no fix until that distribution publishes a fixed version.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | linux | Affected, no fix publishedDebian currently tracks this release as open. | Not published in this feed | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian bookwormbookworm · source | linux | Not affectedDebian marks this release not affected (fixed-version marker 0). | Not published in this feed | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian forkyforky · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.16.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian sidsid · source | linux | Vendor fix publishedDebian records a fixed source-package version for this release. | 6.16.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-aws | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure-fde | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-azure-nvidia | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gcp | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gke | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-gkeop | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-ibm | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-intel | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-lowlatency | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia-lowlatency | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-nvidia-tegra | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-oem-6.11 | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-oracle | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-raspi | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-raspi-realtime | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-realtime | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-riscv | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | linux-xilinx | Affected, no fix publishedCanonical OVAL identifies this running kernel flavour as affected and does not publish a fixed package version in this definition. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
High technical severity; prioritise exposed affected systems while verifying vendor guidance. Verified remediation exists for at least one product or source, but 22 structured product or package states remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Fix availability varies by productIn 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.
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.
The current structured CVE record identifies a security weakness, but the root cause requires confirmation in the linked vendor material.
An attacker operating through local access may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The current structured CVE record identifies a security weakness, but the root cause requires confirmation in the linked vendor material.
An attacker operating through local access may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 9 Oct 2025 · Last source change 11 May 2026, 21:39 UTC · CWE not yet assigned
Missing structured fields: CWE classification. Missing data is not evidence of low risk; review the primary advisory.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.