CVE-2026-89805 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/pagemap: Fix folio allocation fallback and use-after-put
drm_pagemap_migrate_populate_ram_pfn() had two issues when populating RAM PFNs with higher-order folios:
1. The higher-order vma_alloc_folio()/folio_alloc() calls did not pass __GFP_NOWARN, so a THP allocation failure under memory pressure would spam the kernel log, and there was no fallback path despite a TODO comment stating one was needed. Add __GFP_NOWARN to the higher-order allocation and, on failure, fall back to order-0 allocations for the entire range originally covered by the failed higher-order allocation, leaving MIGRATE_PFN_COMPOUND unset for those PFNs.
2. In the free_pages error path, order was computed via folio_order(page_folio(page)) *after* put_page(page) had already dropped the reference, resulting in a use-after-free/put when that was the last reference on the page. Compute order before releasing the page.
Introducing the fallback in 1. also requires the source page array handed to ->copy_to_ram() to be built differently. Both callers only populated the entry at the head of each source folio, relying on the copy callback to derive the rest of the folio from the order recorded in the matching drm_pagemap_addr. Once the destination has been demoted to order-0 folios the drm_pagemap_addr entries are per-page, so a source page is needed for every one of them; leaving them NULL makes the copy callback stop after the first page and the remainder of the range is never copied.
The source folio is only split later, by migrate_vma_pages() / migrate_device_pages(), so its order cannot be used to detect the demotion - test the destination for MIGRATE_PFN_COMPOUND instead. Factor the array population out into drm_pagemap_migrate_populate_src_pages() and use it from both drm_pagemap_evict_to_ram() and __drm_pagemap_migrate_to_ram().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability in the DRM pagemap subsystem addresses critical issues related to memory management during page migration operations, specifically within the drm_pram_map_migrate_populate_ram_pfn function. This flaw manifests primarily through two distinct technical failures: an unhandled allocation failure path that leads to excessive logging and incomplete data copying, and a use-after-put error resulting in potential kernel instability or crashes. The first issue arises when attempting to allocate higher-order folios for RAM page frame number population. Higher-order allocations request multiple contiguous physical pages, which are significantly more susceptible to failure under memory pressure compared to standard single-page allocations. Previously, these allocation calls lacked the __GFP_NOWARN flag, causing kernel logs to be flooded with warning messages whenever an allocation failed due to fragmentation or low memory conditions. More critically, there was no fallback mechanism implemented despite existing code comments indicating that one was necessary. This absence of a graceful degradation path meant that when higher-order allocations failed, the operation would not proceed correctly, potentially leaving system state inconsistent and causing user-space applications relying on DRM operations to fail unexpectedly.
The second issue involves a severe use-after-free vulnerability in the error handling path for freeing pages. The code originally computed the folio order by calling folio_order(page_folio(page)) after put_page(page) had already been executed. Since put_page decrements the reference count of the page structure, if this was the last reference held on that specific page object, it would be freed and returned to the kernel's memory management subsystem for reuse. Accessing or querying properties such as the order of a page that has already been released constitutes a use-after-free condition. This can lead to reading stale data from reclaimed memory, causing incorrect logic execution, potential information disclosure if sensitive data resides in the reused memory block, or immediate kernel panic due to accessing invalid memory structures. Correcting this requires computing the order before releasing any references to ensure the page structure remains valid during inspection.
The resolution of these issues necessitates a structural change in how source pages are prepared for migration callbacks. The introduction of a fallback mechanism that demotes higher-order allocations to order-0 folios creates a mismatch with existing assumptions about data structures. Previously, callers populated only the head entry of each source folio array because the copy callback could derive information about subsequent pages from the order stored in drm_pagemap_addr metadata. However, when the destination is demoted to individual single-page allocations, those metadata entries become per-page rather than per-folio. Consequently, relying on a single populated entry causes the copy callback to terminate prematurely after processing only the first page of each range. This results in significant data loss where the remainder of the memory range intended for migration remains uncopied, leading to corrupted state or application errors when accessing migrated buffers.
To address these complexities, the fix involves refactoring the source array population logic into a dedicated helper function named drm_pagemap_migrate_populate_src_pages. This ensures that every page in the destination range has a corresponding valid entry in the source page array, regardless of whether the underlying allocation was originally high-order or demoted to order-0. The solution also adjusts how folio status is detected during migration; instead of relying on the source folio's order which may no longer reflect the actual state after potential splitting by migrate_vma_pages or migrate_device_pages, the code now tests the destination for the MIGRATE_PFN_COMPOUND flag. This provides a more accurate indication of whether compound page handling is required. These changes are applied consistently across both drm_pagemap_evict_to_ram and __drm_pram_map_migrate_to_ram functions to ensure uniform behavior.
From a security perspective, this vulnerability aligns with CWE-416 Use After Free, which describes the danger of accessing memory after it has been freed, potentially leading to arbitrary code execution or denial of service depending on how the kernel handles the corrupted state. Additionally, the lack of proper error handling and fallback mechanisms relates to CWE-755 Improper Handling of Exceptional Conditions, as the system failed to gracefully manage resource allocation failures. In terms of attack vectors, an attacker with local access could potentially trigger memory pressure conditions or specific race conditions during DRM operations to induce these errors, leading to a denial of service via kernel panic or log flooding that degrades system performance. The fix mitigates these risks by ensuring robust error handling, preventing invalid memory accesses through correct reference counting order, and guaranteeing complete data integrity during page migration processes. This enhancement improves the overall stability and security posture of the Linux DRM subsystem under high-load scenarios.