{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-90387","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-09-11T19:38:34.809Z","datePublished":"2026-09-17T16:09:22.493Z","dateUpdated":"2026-09-18T17:55:01.310Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-09-18T17:55:01.310Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: Preserve allocation virtual address for dynamic pools\n\nswiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted\npool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the\natomic pool is backed by remapped virtual addresses, which are not the same\nas the direct-map addresses returned by phys_to_virt().\n\nswiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address\nfrom the physical start address. For atomic-pool backed allocations this\nstores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes\nthat address to dma_free_from_pool(), which will fail to recognize the\nchunk\n\nPass the virtual address returned by the allocation path into\nswiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This\nkeeps the pool free path using the same virtual address as the allocator."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The mismatch is kernel-internal: swiotlb_init_io_tlb_pool() stored phys_to_virt(start) instead of the remapped cpu_addr from dma_alloc_from_pool(), not bytes from a protocol message. Local I/O reaches it via dma_map_page_attrs() → dma_direct_map_phys() → swiotlb_map() → swiotlb_tbl_map_single() → swiotlb_find_slots() GFP_NOWAIT transient allocation.\nAC:L - On an ARM64 realm guest force_dma_unencrypted() is true, so every GFP_NOWAIT swiotlb_alloc_tlb() in swiotlb_find_slots() uses dma_alloc_from_pool() and CONFIG_DMA_DIRECT_REMAP makes that vaddr differ from phys_to_virt(); filling io_tlb_default_mem then unmapping is attacker-driven I/O with no race.\nPR:L - No capability check gates dma_map_page_attrs() or swiotlb_tbl_map_single(). An unprivileged user triggers the GFP_NOWAIT transient pool by ordinary I/O, e.g. virtio-blk virtqueue_add_sgs() → virtqueue_map_page_attrs(), or sendmsg on virtio-net, which bounce through SWIOTLB_FORCE on a CCA guest.\nUI:N - The attacker’s own map/unmap I/O allocates the transient pool and later dma_direct_unmap_phys() → __swiotlb_tbl_unmap_single() → swiotlb_del_transient() → swiotlb_dyn_free() → swiotlb_free_tlb(); no victim mount or other action is required.\nS:U - pool->start remains page_to_phys(tlb), so the device still DMAs to the allocated bounce pages. The defect is swiotlb_free_tlb() passing the linear phys_to_virt address into dma_free_from_pool()/__free_pages, corrupting the guest page allocator, not an IOMMU map of foreign pages or a realm/host escape.\nC:H - When dma_free_from_pool() rejects the linear address, swiotlb_free_tlb() still __free_pages()s those atomic-pool frames while gen_pool still owns them and dma_common_contiguous_remap() leaves a decrypted VM_DMA_COHERENT alias, so the pages can be reallocated with a stale kernel mapping.\nI:H - atomic_pool_expand() allocated one high-order compound page that gen_pool carved up; __free_pages(virt_to_page(linear_vaddr), get_order(tlb_size)) is a wrong-order or tail-page free of that block, corrupting buddy metadata and yielding an arbitrary write primitive.\nA:H - The same __free_pages() of a compound tail page or the wrong order produces bad-page handling, VM_BUG, or an oops, and any leftover coherent remap or reused frame later panics when touched."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/dma/swiotlb.c"],"versions":[{"version":"79636caad3618e2b38457f6e298c9b31ba82b489","lessThan":"68bf3ebd8e7020dae58e8aa14c7d482738bff9a8","status":"affected","versionType":"git"},{"version":"79636caad3618e2b38457f6e298c9b31ba82b489","lessThan":"45507dcb0847e96add4455274b12df0eca6590b4","status":"affected","versionType":"git"},{"version":"79636caad3618e2b38457f6e298c9b31ba82b489","lessThan":"35e0103177826430b5df888b1506239d41e76ab5","status":"affected","versionType":"git"},{"version":"79636caad3618e2b38457f6e298c9b31ba82b489","lessThan":"c1f4d7763cdf1b9e0d35c14aa6f52d0512a36319","status":"affected","versionType":"git"},{"version":"79636caad3618e2b38457f6e298c9b31ba82b489","lessThan":"57d29044d0f29a76c6ec0c112c8c7371d5608dc7","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["kernel/dma/swiotlb.c"],"versions":[{"version":"6.6","status":"affected"},{"version":"0","lessThan":"6.6","status":"unaffected","versionType":"semver"},{"version":"6.6.157","lessThanOrEqual":"6.6.*","status":"unaffected","versionType":"semver"},{"version":"6.12.110","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.18.52","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.2.6","lessThanOrEqual":"7.2.*","status":"unaffected","versionType":"semver"},{"version":"7.3-rc1","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6","versionEndExcluding":"6.6.157"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6","versionEndExcluding":"6.12.110"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6","versionEndExcluding":"6.18.52"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6","versionEndExcluding":"7.2.6"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.6","versionEndExcluding":"7.3-rc1"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/68bf3ebd8e7020dae58e8aa14c7d482738bff9a8"},{"url":"https://git.kernel.org/stable/c/45507dcb0847e96add4455274b12df0eca6590b4"},{"url":"https://git.kernel.org/stable/c/35e0103177826430b5df888b1506239d41e76ab5"},{"url":"https://git.kernel.org/stable/c/c1f4d7763cdf1b9e0d35c14aa6f52d0512a36319"},{"url":"https://git.kernel.org/stable/c/57d29044d0f29a76c6ec0c112c8c7371d5608dc7"}],"title":"swiotlb: Preserve allocation virtual address for dynamic pools","x_generator":{"engine":"bippy-1.2.0"}}}}