CVE-2026-90387: swiotlb: Preserve allocation virtual address for dynamic pools
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Preserve allocation virtual address for dynamic pools
swiotlballoctlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIGDMADIRECTREMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phystovirt().
swiotlbinitiotlbpool() 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, swiotlbfreetlb() passes that address to dmafreefrompool(), which will fail to recognize the chunk
Pass the virtual address returned by the allocation path into swiotlbinitiotlbpool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator.
Affected Software
Event History
Frequently Asked Questions
Which kernel configurations and allocation paths are relevant to this issue?
The affected path requires a decrypted pool to be allocated from atomic context and CONFIG_DMA_DIRECT_REMAP to be enabled. In that configuration, the DMA atomic pool uses remapped virtual addresses rather than direct-map addresses.
What happens when the affected pool is freed?
The pool records a virtual address reconstructed from its physical address instead of the address returned by the allocator. As a result, dma_free_from_pool() does not recognize the allocation chunk when swiotlb_free_tlb() attempts to free it.
What does the resolved change do?
It passes the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool() and stores that value in pool->vaddr. This ensures the free path uses the same virtual address used by the allocator.