HIGH Introduced in 6.6
swiotlb DynamicPool Address Mismatch
CVE-2026-90387
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
KernelScan AI5.4MEDIUM
01Description
In the Linux kernel, the following vulnerability has been resolved: swiotlb: Preserve allocation virtual address for dynamic pools swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.
02KernelScan AI Analysis
Risk summary
A mismatch between the virtual address stored for a dynamically allocated SWIOTLB pool and the address used during free leads to a failure to recognize and properly free the memory chunk. This can result in memory corruption or resource leaks when the SWIOTLB falls back to transient pools under memory pressure or when DMA memory encryption is active. Local attackers with low privileges can trigger this through DMA operations on affected configurations.
Vulnerability analysis
When the SWIOTLB subsystem needs extra memory for bouncing DMA transfers, it can fall back to a transient pool allocated from an atomic memory pool. On systems where memory encryption is active and DMA remapping is enabled, that atomic pool uses remapped virtual addresses. The buggy code reconstructed the virtual address from the physical address during pool setup, producing a stale direct-map address instead of the actual remapped one. When the pool is later freed, that stale address is not recognized by the allocator, so the memory chunk leaks. The fix preserves the true virtual address from the allocation path through to pool setup and teardown, ensuring the same address is used for both allocation and free. The bug can be triggered locally by unprivileged processes performing I/O that exhausts the bounce buffer pool on affected configurations.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.6 | 6.6 | 6.6.157 | 68bf3ebd8e70 |
| 6.18 | 6.6 | 6.18.52 | 35e010317782 |
| 7.2 | 6.6 | 7.2.6 | c1f4d7763cdf |
| mainline | 6.6 | 7.3-rc1 | 57d29044d0f2 |
| 6.12 | 6.6 | 6.12.110 | 45507dcb0847 |
| cip/6.12 | 6.6 | 6.12.111-cip32 | 45507dcb0847 |