CVE-2026-98254: swiotlb: use the adjusted address for the highmem page lookup
In the Linux kernel, the following vulnerability has been resolved:
swiotlb: use the adjusted address for the highmem page lookup
swiotlbbounce() reads the page frame number from the slot's recorded origaddr, then advances origaddr by tlboffset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it.
Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlboffset, one above for a negative one. DMAFROMDEVICE writes the device data over the wrong page and leaves the intended one stale, DMATODEVICE feeds the device from a page the mapping may not cover. Partial syncs through dmasyncsinglerangefor() are what make tlboffset non-zero.
The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phystovirt().
Take both from origaddr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
What usage pattern triggers the incorrect address calculation?
The issue requires a non-zero tlb_offset. Partial synchronization through dma_sync_single_range_for_*() is what makes tlb_offset non-zero.
What is the impact for DMA transfers?
For DMA_FROM_DEVICE, device data can be written to the wrong page while the intended page remains stale. For DMA_TO_DEVICE, the device can be supplied data from a page that the mapping may not cover.
Are highmem transitions relevant to exploitation?
Yes. An address recorded in lowmem can be adjusted into highmem, while the code still selects the lowmem path and passes a highmem address to phys_to_virt().
How does the direction of the offset affect the misplaced copy?
When the adjustment crosses a page boundary, a positive tlb_offset causes the copy to land one page below the intended page. A negative tlb_offset causes it to land one page above.