CVE-2026-64152 in Linuxinfo

Summary

by MITRE • 07/19/2026

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.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 07/19/2026

The vulnerability resides within the linux kernel's input/output memory management unit implementation where improper error handling during IOMMU mapping operations creates a condition that leads to inconsistent debugging trace records and potential system instability. This issue specifically manifests when the iommu_debug feature is enabled, creating a scenario where error paths in the mapping process fail to maintain proper tracking state between map and unmap operations.

The technical flaw occurs due to an incorrect sequence in the error handling flow within the IOMMU subsystem. When an error occurs during mapping operations, the system attempts to call iommu_unmap() which subsequently invokes iommu_debug_unmap_begin() and iommu_debug_unmap_end() functions. However, since this represents an error path, the original iommu_debug_map() function was never successfully executed to establish the proper tracking state. This creates a mismatch where unmap operations attempt to clean up traces that were never properly established.

The operational impact of this vulnerability extends beyond simple tracing inconsistencies to potentially affect system stability and debugging capabilities in production environments where IOMMU debugging is enabled for troubleshooting or security analysis purposes. The malformed trace records can confuse monitoring systems and make it difficult to correlate actual memory mapping operations with their corresponding cleanup activities, effectively undermining the reliability of debugging information.

This vulnerability aligns with CWE-691, which addresses insufficient control flow management in error handling paths, and represents a specific case where improper state management during exceptional conditions creates inconsistent system behavior. The fix implements a reordering of operations within iommu_map_nosync() to ensure that trace_map()/iommu_debug_map() records are established first before any potential unmap operations occur, thereby creating balanced tracking states.

The mitigation strategy involves lifting the unmap error handling into iommu_map_nosync() and restructuring the execution flow so that partial mappings are recorded immediately before being cleaned up. This approach prevents the creation of unbalanced tracking states where unmap operations would otherwise reference non-existent map operations, thus providing saner tracing behavior that maintains proper correlation between mapping and unmapping activities.

The solution addresses ATT&CK technique T1562.007 by ensuring proper system integrity during error handling operations within the kernel's memory management subsystem. This prevents potential exploitation scenarios where malformed IOMMU trace states could be manipulated to bypass security controls or create denial of service conditions. The fix maintains the debugging functionality while ensuring that all trace operations remain consistent and predictable, thereby preserving both system stability and forensic capabilities for security analysis purposes.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!