Skip to content
CVE Ledger
  • Newest CVEsPage
  • Recently added to KEVPage
  • Rising exploitation (EPSS)Page
  • Weekly digestPage
  • StatisticsPage
  • WatchlistPage
  • API docsPage
  • MCP serverPage
  • AboutPage
  • Data sourcesPage
  • Data statusPage
  • ChangelogPage
  • How it's builtPage
  • Support the projectPage

14 results

Back

CVE-2026-64149dma-mapping: move dma_map_resource() sanity check into debug code

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.

Timeline

  1. ID reserved

    By Linux

  2. Published

Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.

Scores

CVSS scores of CVE-2026-64149, by who scored it
Scored byCVSSScoreVector
NVDNVD · Analyzed3.1Medium5.5CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS (exploitation in 30 days)
0.16% · top 95% of all CVEs (14 Nov 2026)
Loading the EPSS history…

The list uses the assigner's score when there is one, then CISA's, then NVD's: Medium 5.5.

Affected products

  • Linux · Linux

    • affected f7326196a781622b33bfbdabb00f5e72b5fb5679 – < 181e67bc11c5ec5b87c6c512c2078752b23ca8d4
    • affected f7326196a781622b33bfbdabb00f5e72b5fb5679 – < 004a777879ff629f6e0ca3d09ad09fa3452bcc4d
    • affected f7326196a781622b33bfbdabb00f5e72b5fb5679 – < af0c3f05866237f7592219bfe05387bc3bfc99b5
  • Linux · Linux

    • affected 6.18
    • unaffected < 6.18
    • unaffected 6.18.34 – ≤ 6.18.*
    • unaffected 7.0.11 – ≤ 7.0.*
    • unaffected 7.1 – ≤ *

References

References3

Sources

The same CVE in the primary databases and aggregators, to check against.

Badge for a README or a ticket

CVE-2026-64149 badge
[![CVE-2026-64149](https://cveledger.app/badge/CVE-2026-64149.svg)](https://cveledger.app/cve/CVE-2026-64149)

Record last updated .