CVE-2026-98254
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A mistake in how the Linux kernel moves data between devices and high memory can let a local attacker corrupt system memory or gain higher privileges.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Data Tampering
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Logic error in swiotlb_bounce() that mixes the pre-adjustment orig_addr with the post-adjustment address when performing highmem page lookups; a non-zero tlb_offset that crosses a page boundary causes DMA copies to land on the wrong page, corrupting memory for DMA_FROM_DEVICE writes or supplying incorrect data for DMA_TO_DEVICE reads.
Why it matters to the business
Local memory corruption on Linux systems that use swiotlb for DMA bounce buffering can lead to application or kernel crashes, data integrity failures, or local privilege escalation; the issue is most relevant on systems performing partial DMA syncs.
How an attack unfolds
A local attacker triggers DMA operations that invoke dma_sync_single_range_for_*() to produce a non-zero tlb_offset, then relies on the address mismatch in the highmem branch to read or write an unintended page; the same flawed branch test can also cause a lowmem slot to be treated as highmem, handing an invalid address to phys_to_virt().
How to fix it
Apply the upstream fix that uses the final adjusted orig_addr for both the page and offset in the highmem path; rebuild and deploy the corrected kernel.
How to confirm the fix worked
Confirm the corrected code path by inspecting swiotlb_bounce() to ensure orig_addr is finalized before the highmem branch and that pfn is taken only from the final address; run DMA sync regression tests that exercise partial-range operations.
Typical attack path
- Obtain local unprivileged access on a Linux system using swiotlb
- Craft or trigger DMA I/O that performs a partial-range sync producing non-zero tlb_offset
- Force the highmem lookup path to use mismatched page and offset values
- Achieve out-of-bounds read or write into kernel memory
- Escalate privileges or induce denial of service
How to detect it
Examine kernel logs and crash reports for DMA bounce or swiotlb errors coinciding with partial sync operations; no public exploit artifacts are known.
What your security team should do
- Prioritize kernel updates on systems that rely on swiotlb (especially embedded or virtualization hosts)
- Restrict unprivileged local access until patches are deployed
- Monitor kernel logs and crash dumps for DMA-related memory corruption signatures
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|