PT-2026-61466 · Linux · Linux
CVE-2026-64149
·
Published
2026-07-19
·
Updated
2026-07-19
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: move dma map resource() sanity check into debug code
dma map resource() uses pfn valid() to ensure the range is not RAM.
However, pfn valid() only checks for availability of the memory map for
a PFN but it does not ensure that the PFN is actually backed by RAM. On
ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that
share a section with RAM will falsely trigger the WARN ON ONCE and cause
dma map resource() to return DMA MAPPING ERROR.
This causes a WARNING on Raspberry Pi 4 during spi bcm2835 probe because
the SPI FIFO register (0xfe204004) falls in the same sparsemem section
as the end of RAM (0xf8000000-0xfbffffff), both in section 31
(0xf8000000-0xffffffff).
Move the sanity check from dma map resource() into debug dma map phys()
and replace the unreliable pfn valid() with pfn valid() &&
!PageReserved(), which correctly identifies actual usable RAM without
false positives for MMIO regions that happen to have struct pages.
Since dma map resource() is dma map phys(DMA ATTR MMIO), the check
applies equally to both APIs. Any non-reserved page represents kernel
memory to a sufficient degree that using DMA ATTR MMIO on it is almost
certainly wrong and risks breaking coherency on non-coherent platforms.
ZONE DEVICE pages used for PCI P2P DMA (MEMORY DEVICE PCI P2PDMA) have
PageReserved set, so they will not trigger a false positive.
The check no longer blocks the mapping and uses err printk() to
integrate with dma-debug filtering.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux