CVE-2026-64149

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-mapping: move dma_map_resource() sanity check into debug code<br /> <br /> dma_map_resource() uses pfn_valid() to ensure the range is not RAM.<br /> However, pfn_valid() only checks for availability of the memory map for<br /> a PFN but it does not ensure that the PFN is actually backed by RAM. On<br /> ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that<br /> share a section with RAM will falsely trigger the WARN_ON_ONCE and cause<br /> dma_map_resource() to return DMA_MAPPING_ERROR.<br /> <br /> This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because<br /> the SPI FIFO register (0xfe204004) falls in the same sparsemem section<br /> as the end of RAM (0xf8000000-0xfbffffff), both in section 31<br /> (0xf8000000-0xffffffff).<br /> <br /> Move the sanity check from dma_map_resource() into debug_dma_map_phys()<br /> and replace the unreliable pfn_valid() with pfn_valid() &amp;&amp;<br /> !PageReserved(), which correctly identifies actual usable RAM without<br /> false positives for MMIO regions that happen to have struct pages.<br /> <br /> Since dma_map_resource() is dma_map_phys(DMA_ATTR_MMIO), the check<br /> applies equally to both APIs. Any non-reserved page represents kernel<br /> memory to a sufficient degree that using DMA_ATTR_MMIO on it is almost<br /> certainly wrong and risks breaking coherency on non-coherent platforms.<br /> ZONE_DEVICE pages used for PCI P2P DMA (MEMORY_DEVICE_PCI_P2PDMA) have<br /> PageReserved set, so they will not trigger a false positive.<br /> <br /> The check no longer blocks the mapping and uses err_printk() to<br /> integrate with dma-debug filtering.