CVE-2026-98254 swiotlb: use the adjusted address for the highmem page lookup

High 7.8 Published Updated

A Linux kernel bug in swiotlb causes incorrect memory access during DMA operations, potentially leading to data corruption or exposure.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2026-98254?

CVE-2026-98254 is a high-severity memory corruption vulnerability in Linux, published on 6 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official 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.

Which versions are affected by CVE-2026-98254?

How do I fix CVE-2026-98254?

Apply the vendor's patch.

Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.

Is CVE-2026-98254 being exploited?

There is no known exploitation of CVE-2026-98254 in the wild and no public exploit code.

Sources

Also known as AZL-106281, BELL-CVE-2026-98254, DEBIAN-CVE-2026-98254, GHSA-hrh5-h3h2-8q3j, UBUNTU-CVE-2026-98254.

Is CVE-2026-98254 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free