In the Linux kernel, the swiotlb allocator can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP enabled, the atomic pool is backed by remapped virtual addresses that differ from the direct‑map addresses returned by phys_to_virt(). The initialization routine mistakenly reconstructs a virtual address from the physical start address, thereby storing an incorrect pool->vaddr. When freeing, swiotlb_free_tlb() passes this bogus address to dma_free_from_pool(), which fails to recognize the memory chunk. The result is a kernel memory leak or corruption that may exhaust kernel address space or corrupt critical kernel structures. This memory‑management flaw can lead to a denial‑of‑service condition.

The flaw resides in the Linux kernel itself, affecting any kernel that includes the swiotlb allocator and uses the CONFIG_DMA_DIRECT_REMAP option. Specific kernel releases are not enumerated, so all builds that contain the buggy allocation path and enable the remapped pool configuration are potentially vulnerable. Users should check whether their kernel version contains the relevant swiotlb code and verify if the CONFIG_DMA_DIRECT_REMAP setting is active.

The CVSS score of 7.8 indicates a high severity. The EPSS score of less than 1% suggests that the likelihood of exploitation at present is very low, and the vulnerability is not listed in CISA's KEV catalog. The inference is that the attack vector is local: an attacker would need to exercise control over the kernel to trigger the allocation and deallocation sequences that invoke the flawed virtual‑address handling, typically via a local privilege escalation or kernel exploitation scenario.