Description

In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset 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 tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset 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 phys_to_virt(). Take both from orig_addr 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:14.057Z",
  "pubdate": "2026-10-06T09:18:14.057Z",
  "executiveSummary": "This vulnerability exists within the Linux kernel's Software Input-Output Translation Buffer (SWIOTLB) subsystem, specifically within the swiotlb_bounce() function.\nThe issue is classified as an Improper Input Validation leading to memory corruption, specifically an out-of-bounds access scenario during DMA operations.\nThe vulnerability occurs when partial synchronization operations (via dma_sync_single_range_for_*) result in a non-zero tlb_offset, causing the kernel to incorrectly calculate the page frame number for highmem pages.\nAn attacker capable of triggering DMA operations via a device driver could potentially leverage this flaw to read from or write to unintended memory locations.\nThis can lead to memory corruption, potential kernel panic, or unauthorized access to sensitive data structures if a highmem page is incorrectly identified or overwritten.\nThe vulnerability affects systems relying on SWIOTLB for DMA mapping, particularly those where bounce buffering is utilized for highmem pages.\nSuccessful exploitation requires the ability to influence or trigger specific DMA synchronization routines that involve cross-page boundary offsets.",
  "technicalDetails": "The vulnerability resides in the swiotlb_bounce() function, which is responsible for copying data between bounce buffers and original buffers during DMA operations.\nThe root cause is an architectural flaw in how the kernel derives the page and offset from the original address during highmem page lookups. The implementation erroneously mixes two disparate sources: it reads the Page Frame Number (PFN) from the slot's original, unadjusted address, while simultaneously using the offset from the adjusted address (orig_addr + tlb_offset).\nWhen a partial sync operation causes tlb_offset to cross a page boundary, the derived PFN and the offset no longer correspond to the same physical memory location. Specifically, the kernel calculates a memory address one page removed from the intended target—either below for positive offsets or above for negative offsets.\nIn a DMA_FROM_DEVICE scenario, the kernel writes device data into the incorrect page, leaving the intended target memory stale and potentially overwriting legitimate, unrelated kernel memory. In a DMA_TO_DEVICE scenario, the kernel may feed data to the device from a memory region not intended for the mapping.\nFurthermore, the logic used to determine whether a page is in highmem is inconsistent. A slot recorded in lowmem can be adjusted into highmem, but the subsequent check might still follow the lowmem path, leading the kernel to pass a highmem address to phys_to_virt(). Because phys_to_virt() is not safe for highmem addresses, this causes memory access violations or dereferencing of invalid virtual mappings.\nThe exploitation flow involves: 1) Establishing a DMA mapping that necessitates bounce buffering; 2) Triggering a partial sync (dma_sync_single_range_for_*) to induce a non-zero tlb_offset that crosses a page boundary; 3) Initiating a DMA operation that triggers swiotlb_bounce(). By controlling the timing and parameters of these DMA operations, an attacker could manipulate the kernel's memory state, potentially leading to unauthorized data modification or system instability.\nThe corrected logic must ensure that both the PFN and the offset are derived from the final, adjusted address. By ensuring consistent address evaluation, the kernel avoids the mismatch that currently causes the PFN/offset pair to point to the incorrect memory location."
}