In the Linux kernel, the following vulnerability has been resolved: dma-mapping: move dma_map_resource() sanity check into debug code… (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.
AI Analysis
Technical Summary
The Linux kernel vulnerability CVE-2026-64149 involved dma_map_resource() using pfn_valid() alone to verify that a memory range was not RAM before mapping it for DMA. On ARM64 systems with SPARSEMEM, this caused false positives for MMIO addresses sharing sections with RAM, triggering warnings and mapping errors, notably on Raspberry Pi 4 during SPI driver initialization. The fix moves the sanity check into debug_dma_map_phys() and replaces pfn_valid() with pfn_valid() && !PageReserved(), which accurately identifies usable RAM and avoids false positives for MMIO regions. This change prevents incorrect blocking of DMA mappings and integrates error reporting with dma-debug filtering.
Potential Impact
The vulnerability caused false warnings and DMA mapping errors on affected ARM64 systems with SPARSEMEM, potentially disrupting device driver initialization (e.g., SPI on Raspberry Pi 4). It did not directly allow unauthorized access or code execution but could lead to functional issues or degraded device operation due to incorrect DMA mapping behavior.
Mitigation Recommendations
This vulnerability has been resolved in the Linux kernel by moving the sanity check into debug code and improving the validation logic. Users should update to a Linux kernel version that includes this fix. Since this is a kernel-level fix, applying the official kernel update from the vendor or distribution is the recommended remediation. Patch status is not explicitly stated here; check the vendor or Linux kernel mailing lists for the specific fixed kernel version.
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: move dma_map_resource() sanity check into debug code… (CVE-2026-64149)
Description
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.
CVSS v3.1
Score 5.5medium
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel vulnerability CVE-2026-64149 involved dma_map_resource() using pfn_valid() alone to verify that a memory range was not RAM before mapping it for DMA. On ARM64 systems with SPARSEMEM, this caused false positives for MMIO addresses sharing sections with RAM, triggering warnings and mapping errors, notably on Raspberry Pi 4 during SPI driver initialization. The fix moves the sanity check into debug_dma_map_phys() and replaces pfn_valid() with pfn_valid() && !PageReserved(), which accurately identifies usable RAM and avoids false positives for MMIO regions. This change prevents incorrect blocking of DMA mappings and integrates error reporting with dma-debug filtering.
Potential Impact
The vulnerability caused false warnings and DMA mapping errors on affected ARM64 systems with SPARSEMEM, potentially disrupting device driver initialization (e.g., SPI on Raspberry Pi 4). It did not directly allow unauthorized access or code execution but could lead to functional issues or degraded device operation due to incorrect DMA mapping behavior.
Mitigation Recommendations
This vulnerability has been resolved in the Linux kernel by moving the sanity check into debug code and improving the validation logic. Users should update to a Linux kernel version that includes this fix. Since this is a kernel-level fix, applying the official kernel update from the vendor or distribution is the recommended remediation. Patch status is not explicitly stated here; check the vendor or Linux kernel mailing lists for the specific fixed kernel version.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-pxq7-6qx3-6gp9
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64149"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27a82a4a8d598912abd4
Added to database: 07/19/2026, 19:38:16 UTC
Last enriched: 07/19/2026, 19:44:23 UTC
Last updated: 09/02/2026, 22:52:13 UTC
Views: 49
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.