Skip to main content

Linux Kernel CVE-2026-64152

| EUVDEUVD-2026-45837 HIGH
2026-07-19 Linux GHSA-2cx2-4725-6r7g
Information Disclosure Linux
High
Disputed · 7.8 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
3.6 LOW

Local access with low privileges and high complexity to force a mid-map failure on a rare debug-enabled kernel; realistic impact is tracking corruption/instability, so I:L/A:L and no confirmed confidentiality or scope change.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 LOW
qualitative

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 VectorVendor: Linux

Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 17:44 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:03 EUVD
CVE Published
Jul 19, 2026 - 15:40 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 19, 2026 - 15:40 cve.org
HIGH 7.8

DescriptionCVE.org

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

iommu: Handle unmap error when iommu_debug is enabled

Sashiko noticed a latent bug where the map error flow called iommu_unmap() which calls iommu_debug_unmap_begin()/iommu_debug_unmap_end() however since this is an error path the map flow never actually established the original iommu_debug_map() it will malfunction.

Lift the unmap error handling into iommu_map_nosync() and reorder it so the trace_map()/iommu_debug_map() records the partial mapping and then immediately unmaps it. This avoid creating the unbalanced tracking and provides saner tracing instead of a unmap unmatched to any map.

AnalysisAI

Improper error-path handling in the Linux kernel IOMMU subsystem allows unbalanced debug-tracking operations when CONFIG_IOMMU_DEBUG is enabled and an IOMMU map operation fails partway. When iommu_map_nosync() hits an error, the cleanup path invoked iommu_unmap()/iommu_debug_unmap_begin()/end() against a mapping the debug layer never recorded via iommu_debug_map(), corrupting internal tracking state and producing spurious unmatched trace records. The fix lifts unmap error handling into iommu_map_nosync() and reorders it so trace_map()/iommu_debug_map() records the partial mapping before immediately unmapping it. This is a locally-scoped, debug-configuration-dependent issue with no public exploit identified at time of analysis; EPSS is low (0.15%, 5th percentile) and it is not in CISA KEV.

Technical ContextAI

The affected component is the Linux kernel IOMMU (Input-Output Memory Management Unit) core, specifically the DMA-remapping map/unmap accounting used to translate device DMA addresses to physical memory. The kernel provides an optional debug facility (iommu_debug) that instruments map/unmap calls via iommu_debug_map_begin/end and iommu_debug_unmap_begin/end, plus tracepoints (trace_map). The root cause is a state-management/error-handling flaw (best classed as CWE-754 Improper Check for Unusual or Exceptional Conditions / improper cleanup on failure; the input lists CWE as N/A): during a failed map, the rollback path called the unmap-side debug hooks for a mapping that was never registered on the map side, creating an unbalanced, inconsistent tracking record. Per the CPE data (cpe:2.3:a:linux:linux) the affected product is the mainline Linux kernel; the EUVD/git.kernel.org references pin the fix to stable commits ccc21213f013 through 0735c5480 / 0cd028806efc.

RemediationAI

Patch available per vendor advisory: apply the upstream kernel fix delivered in the referenced stable commits (0735c54804c709d1b292f3b6947cfb560b2ce552 and 0cd028806efc148a75d4acf711d21db335a89661) by updating to a distribution kernel that incorporates them, then reboot to load the patched kernel - no exact tagged release version is provided in the input, so confirm the fixed package build with your distribution's security tracker before deployment. See https://git.kernel.org/stable/c/0cd028806efc148a75d4acf711d21db335a89661 and https://git.kernel.org/stable/c/0735c54804c709d1b292f3b6947cfb560b2ce552. As an effective compensating control until patched, disable the IOMMU debug facility by building/running a kernel without CONFIG_IOMMU_DEBUG, since the faulty code path is only reachable when iommu_debug is enabled; the trade-off is loss of IOMMU debug instrumentation, which is acceptable for production systems that do not need it. Additionally restrict local access and the ability to trigger IOMMU map operations (e.g., limit privileged device/DMA configuration to trusted administrators), noting this reduces but does not eliminate exposure on debug-enabled kernels.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-64152 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy