CVE-2026-53164 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
iommu/dma: Do not try to iommu_map a 0 length region in swiotlb
iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommu_map() with a 0 size which the iommupt implementation will fail as illegal.
It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARN_ON.
Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink.
This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/26/2026
This vulnerability exists within the linux kernel's iommu dma subsystem where a specific edge case in the software iommu translation path causes system instability and potential security implications. The flaw manifests in the iommu_dma_iova_link_swiotlb() function which handles memory mapping operations for devices that require IOMMU protection, particularly those using software-based IOMMU implementations. When processing memory regions that are unaligned, the function splits the mapping into head, middle, and trailer segments to ensure proper alignment with IOMMU page boundaries.
The technical flaw occurs when the middle portion of an unaligned memory region contains no aligned pages, resulting in a zero-length segment that gets passed to the iommu_map() function. This function implementation strictly validates input parameters and rejects any mapping operation with a zero length parameter as illegal, causing immediate failure of the mapping process. The vulnerability extends beyond simple parameter validation failure into improper error handling where the system attempts to unwind the failed mapping operation but starts from an incorrect offset position.
This incorrect unwinding process corrupts the existing memory mapping structures and leads to subsequent cleanup operations that trigger kernel warnings and potential system instability. The root cause stems from the function's logic which does not properly check for zero-length regions before attempting the IOMMU mapping operation, creating a scenario where the error recovery mechanism itself becomes corrupted. This type of vulnerability falls under CWE-129 Input Validation and CWE-704 Incorrect Calculation as it involves improper handling of memory boundaries and arithmetic operations.
The operational impact of this vulnerability is significant as it can cause system crashes or unpredictable behavior when devices that require software IOMMU translation attempt to access memory with specific alignment patterns. The vulnerability specifically affects systems using thunderbolt NVMe drives which have been observed to trigger forced SWIOTLB for unaligned memory operations during SMART command processing. This particular use case demonstrates how storage device firmware interactions can inadvertently create conditions that expose kernel-level memory management flaws, making it particularly concerning for enterprise and consumer systems alike.
The vulnerability is mitigated through proper parameter validation before IOMMU mapping operations are initiated, ensuring that zero-length regions are detected and handled appropriately without attempting invalid mapping operations. The fix involves checking for zero-length regions and avoiding the iommu_map() call entirely while using appropriate offset values when unlinking previously mapped segments during error recovery scenarios. This approach aligns with the ATT&CK framework's defensive techniques focusing on input validation and proper error handling, preventing both immediate system failure and potential exploitation through memory corruption attacks.
This vulnerability represents a classic example of how complex kernel subsystems can fail due to edge cases in memory management operations, particularly when dealing with hardware-specific requirements that force software fallback mechanisms. The interaction between device drivers, memory management subsystems, and IOMMU implementations creates numerous potential failure points where improper boundary handling can lead to system instability. This type of vulnerability is particularly concerning from a security perspective as it could potentially be exploited to cause denial of service or in more complex scenarios, could provide a pathway for privilege escalation through memory corruption attacks that leverage the corrupted mapping structures during cleanup operations.