CVE-2026-53164

What it actually does

This Linux kernel flaw is a denial-of-service class bug in the IOMMU DMA/SWIOTLB mapping path. When an unaligned DMA buffer is split into head, middle, and trailer regions, the middle region can be zero length. The vulnerable code still attempts to call iommu_map() with a zero-sized mapping, which is rejected as illegal. The subsequent error-unwind path can start from the wrong offset, corrupting mapping state and later triggering a kernel WARN_ON during teardown. The issue is most readily triggered by devices or workloads that force SWIOTLB for unaligned DMA, with the upstream description specifically noting some Thunderbolt NVMe drives and smartctl passthrough commands.

Why it matters to the business

The main risk is host instability or service disruption on affected Linux systems, especially systems using IOMMU/SWIOTLB with external or unusual DMA-capable storage devices such as some Thunderbolt NVMe drives. Successful triggering may cause kernel warnings, degraded reliability, device I/O disruption, or in some configurations broader system instability. There is no indication of known exploitation in the wild, CISA KEV listing, ransomware use, or public exploit maturity, and the EPSS score is very low, so broad internet-scale exploitation risk appears limited; however, organizations running Linux endpoints, workstations, or servers with affected kernels and DMA-capable peripherals should still prioritize kernel updates through normal patch cycles.

How an attack unfolds

An attacker or local user must create conditions that cause the Linux kernel to process an unaligned DMA mapping through the IOMMU DMA SWIOTLB path. In practical terms, this may involve attaching or using a DMA-capable device, such as certain Thunderbolt NVMe storage devices, and issuing I/O operations that use oddly aligned buffers, such as NVMe passthrough commands generated by tools like smartctl. The vulnerable kernel splits the mapping into unaligned head, aligned middle, and trailer sections. If there are no aligned pages, the middle section is zero length, but the kernel still attempts a zero-length iommu_map() call. That failure triggers an incorrect unwind path, corrupting the mapping state. When the mapping is later destroyed, the kernel can hit a WARN_ON and may disrupt the affected workload or destabilize the host.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the IOMMU DMA/SWIOTLB zero-length mapping handling. Because no specific affected product list or fixed package versions were provided, use the fixed kernel versions supplied by the relevant Linux distribution or kernel vendor once available. As interim mitigation, reduce exposure to triggering conditions by limiting use of untrusted Thunderbolt or other DMA-capable peripherals, disabling or restricting Thunderbolt where not needed, avoiding affected NVMe passthrough workflows on vulnerable kernels, and applying platform DMA protections such as IOMMU/Thunderbolt security policies. Where operationally feasible, test smartctl/NVMe passthrough workloads against patched kernels before broad deployment.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version includes the vendor fix for the IOMMU DMA/SWIOTLB zero-length mapping bug. Review distribution advisories, kernel changelogs, or package metadata for a fix referencing iommu/dma, swiotlb, zero-length iommu_map, or iommu_dma_iova_link_swiotlb(). After patching and rebooting into the fixed kernel, reproduce previously problematic operations, such as smartctl passthrough against affected Thunderbolt NVMe devices, and confirm that no new kernel WARN_ON, iommu_map zero-size, SWIOTLB, DMA mapping, or IOMMU teardown warnings appear in kernel logs. Also verify that systems are not merely patched on disk but are actively running the updated kernel.

Typical attack path

1. Gain local ability to interact with the affected Linux host or persuade an authorized user to attach/use a triggering DMA-capable device.
2. Use a device or workload that forces SWIOTLB mappings, such as certain Thunderbolt NVMe storage devices.
3. Issue I/O or passthrough operations using unaligned buffers, for example NVMe administrative or SMART passthrough commands.
4. Cause the IOMMU DMA code to split the mapping into head, zero-length middle, and trailer regions.
5. Trigger the invalid zero-length iommu_map() call and faulty unwind behavior.
6. Induce kernel warnings, mapping-state corruption, I/O disruption, or host instability consistent with denial of service.

How to detect it

To determine whether this issue was already triggered, review kernel and system logs for events around DMA-capable storage use, especially Thunderbolt NVMe attachment, NVMe passthrough commands, or smartctl executions. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, dmesg output, audit logs for smartctl or nvme command execution, and endpoint telemetry showing USB4/Thunderbolt device attachment. Look for WARN_ON traces or call stacks referencing iommu_dma_iova_link_swiotlb(), iommu_map(), swiotlb, IOMMU DMA mapping, NVMe passthrough, or teardown/unmap failures. Correlate these with device attach events and smartctl/nvme utility execution. Because this is a kernel reliability flaw rather than a typical remote compromise, evidence is more likely to appear as kernel warnings, stack traces, I/O errors, or sudden reboots than as attacker-created files or network indicators.

• iommu_dma_iova_link_swiotlb
• iommu_map
• swiotlb
• SWIOTLB
• WARN_ON
• WARNING: CPU:
• DMA mapping
• IOMMU
• nvme
• smartctl
• NVMe passthrough
• thunderbolt
• Thunderbolt
• iommu/dma

What your security team should do

• Inventory Linux systems that use IOMMU/SWIOTLB and DMA-capable external peripherals, especially workstations or servers using Thunderbolt NVMe devices.
• Track Linux distribution advisories and schedule kernel updates that include the upstream iommu/dma SWIOTLB fix.
• Prioritize patching systems where local users can attach Thunderbolt or other DMA-capable devices, or where NVMe passthrough tooling such as smartctl is routinely used.
• Temporarily restrict untrusted Thunderbolt/peripheral access on sensitive systems until patched.
• Monitor kernel logs for IOMMU, SWIOTLB, DMA mapping, iommu_map, and WARN_ON messages associated with NVMe passthrough activity.
• After remediation, confirm systems have rebooted into the fixed kernel rather than only installing the package.
• Treat exploitation risk as lower priority than remotely exploitable issues because EPSS is very low, exploit maturity is reported as none, and the issue is not listed in KEV; nevertheless, include it in normal kernel reliability patching.