CVE-2026-64149

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.