CVE-2026-89805: Linux Kernel DRM Use-After-Free Vulnerability

CVE-2026-89805 Overview

CVE-2026-89805 is a use-after-free vulnerability in the Linux kernel's Direct Rendering Manager (DRM) pagemap subsystem. The flaw resides in drm_pagemap_migrate_populate_ram_pfn(), which handled higher-order folio allocations incorrectly when populating RAM page frame numbers (PFNs). Two defects combined to create the issue: a missing __GFP_NOWARN flag with no fallback for failed Transparent Huge Page (THP) allocations, and computation of folio order after the page reference had already been released. A local attacker with low privileges can trigger the vulnerable code path to corrupt kernel memory.

Critical Impact
Local exploitation may lead to kernel memory corruption, privilege escalation, or denial of service on systems using the affected DRM pagemap migration path.

Affected Products

Linux kernel (mainline) containing the drm/pagemap migration code
Distributions shipping the affected drm_pagemap_migrate_populate_ram_pfn() implementation
Systems using DRM device memory migration for GPU workloads

Discovery Timeline

2026-09-16 - CVE-2026-89805 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89805

Vulnerability Analysis

The vulnerability affects drm_pagemap_migrate_populate_ram_pfn() in the Linux kernel DRM subsystem. This function populates RAM PFNs with folios during migration between device memory and system RAM. Two independent defects created exploitable conditions in the higher-order folio allocation path.

The first defect involved higher-order vma_alloc_folio() and folio_alloc() calls that omitted the __GFP_NOWARN flag. Under memory pressure, THP allocation failures produced kernel log noise. More critically, no fallback path existed despite a TODO comment acknowledging the requirement. Callers received allocation failures without graceful degradation.

The second defect is the security-relevant use-after-free. In the free_pages error path, the code computed order via folio_order(page_folio(page)) after put_page(page) had already dropped the reference. When that reference was the last on the page, subsequent access to the folio metadata dereferenced freed memory.

Root Cause

The root cause is incorrect operation ordering in the error cleanup path. The put_page() call may free the underlying page when it drops the final reference. Reading folio state through page_folio(page) afterward accesses memory that the page allocator can reuse. This constitutes a classic use-after-free condition [CWE-416] triggered along an error handling branch.

Attack Vector

Exploitation requires local access with the ability to invoke DRM migration operations. A low-privileged local user with access to a DRM device node can trigger higher-order folio allocation failures under memory pressure. Once the error path executes, the use-after-free window opens. Successful exploitation depends on winning a race to reallocate the freed page with attacker-controlled content before the stale reference is dereferenced.

The upstream fix reorders the operations to compute folio order before releasing the page, adds __GFP_NOWARN to higher-order allocations, and introduces an order-0 fallback path. It also factors source array population into drm_pagemap_migrate_populate_src_pages() and tests the destination for MIGRATE_PFN_COMPOUND to correctly handle demotion. See the kernel commit and the follow-up commit for the complete patch.

Detection Methods for CVE-2026-89805

Indicators of Compromise

Unexpected kernel panics or oops messages referencing drm_pagemap_migrate_populate_ram_pfn or folio_order in the stack trace
KASAN (Kernel Address Sanitizer) reports flagging use-after-free in the DRM pagemap migration code path
Kernel log entries showing THP allocation warnings from DRM device memory migration routines

Detection Strategies

Enable KASAN on test kernels to catch the use-after-free condition during regression testing of GPU workloads
Monitor kernel ring buffer output for oops, WARN, or BUG messages originating in drivers/gpu/drm/drm_pagemap.c
Correlate unexpected DRM device failures with concurrent memory pressure events on affected hosts

Monitoring Recommendations

Collect kernel crash dumps and dmesg output from systems running GPU-accelerated workloads for offline analysis
Track kernel version inventory across the estate to identify unpatched hosts running the vulnerable DRM code
Alert on repeated crashes or restarts of GPU-dependent services that could indicate exploitation attempts

How to Mitigate CVE-2026-89805

Immediate Actions Required

Apply the upstream kernel patches referenced in the two git.kernel.org commits as soon as vendor builds become available
Identify hosts using DRM device memory migration (typically GPU compute and rendering nodes) and prioritize their patching
Restrict access to DRM device nodes (/dev/dri/*) to trusted users where operationally feasible

Patch Information

The fix is delivered in two upstream commits. Commit 10e92e18e3da and commit df72e55e754c together correct the operation ordering, add __GFP_NOWARN, introduce the order-0 fallback, and refactor source page array population. Consume the fix through your Linux distribution's stable kernel updates once backported.

Workarounds

Limit exposure by restricting DRM device access to privileged accounts and containerized workloads with strict device cgroup rules
Reduce memory pressure on affected hosts to minimize the likelihood of triggering the higher-order allocation failure path
Where GPU migration is not required, disable or avoid workloads that invoke the affected DRM pagemap code path until patches are applied

bash

# Check running kernel version and identify DRM device exposure
uname -r
ls -l /dev/dri/
# Restrict DRM device access to the video group
chgrp video /dev/dri/render*
chmod 660 /dev/dri/render*