Incorrect Check of Function Return Value Affecting kernel-rt-debug package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS10-KERNELRTDEBUG-18059292
- published21 Jul 2026
- disclosed19 Jul 2026
Introduced: 19 Jul 2026
NewCVE-2026-64149 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-rt-debug.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt-debug package and not the kernel-rt-debug package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2502492
- https://access.redhat.com/security/cve/CVE-2026-64149
- https://git.kernel.org/stable/c/004a777879ff629f6e0ca3d09ad09fa3452bcc4d
- https://git.kernel.org/stable/c/181e67bc11c5ec5b87c6c512c2078752b23ca8d4
- https://git.kernel.org/stable/c/af0c3f05866237f7592219bfe05387bc3bfc99b5