CVE-2026-64100: Linux Kernel Race Condition Vulnerability

CVE-2026-64100 Overview

CVE-2026-64100 addresses a circular locking dependency in the Linux kernel's Direct Rendering Manager (DRM) subsystem for Qualcomm Adreno GPUs (drm/msm). The flaw manifests when the memory reclaim path invokes the MSM shrinker while holding the fs_reclaim lock. The shrinker subsequently attempts to acquire dma_resv_lock, which itself depends on fs_reclaim, producing a deadlock condition detectable with PROVE_LOCKING.

The issue was reproduced on Snapdragon X1 hardware under virtual memory reclaim pressure. The upstream fix replaces the blocking acquisition with dma_resv_trylock(), dropping the unused wait-wound ticket argument.

Critical Impact
A deadlock in the kswapd memory reclaim path can freeze systems using MSM DRM drivers under memory pressure, effectively producing a local denial-of-service condition.

Affected Products

Linux kernel with the drm/msm driver enabled
Systems using Qualcomm Adreno GPUs (Snapdragon X1 and related SoCs)
Kernel builds prior to the commits referenced in git.kernel.org

Discovery Timeline

2026-07-19 - CVE-2026-64100 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64100

Vulnerability Analysis

The defect is a lock-ordering violation in the MSM GPU shrinker path. When kswapd triggers slab shrinking under memory pressure, it calls msm_gem_shrinker_scan() while already holding fs_reclaim. The shrinker path then calls drm_gem_lru_scan(), which acquires reservation_ww_class_acquire and ultimately reservation_ww_class_mutex. That mutex has a documented dependency on fs_reclaim registered via dma_resv_lockdep() during initialization.

The lockdep report shows the circular chain: reservation_ww_class_acquire → reservation_ww_class_mutex → fs_reclaim → reservation_ww_class_acquire. The PROVE_LOCKING validator detects this as a possible circular locking dependency prior to actual deadlock.

Root Cause

The MSM shrinker used the blocking variant of dma_resv_lock() when scanning GEM buffer objects. Blocking on a dma_resv mutex from within the reclaim path violates the invariant that reclaim-path code must not wait on locks that may depend on fs_reclaim. This falls under kernel driver vulnerabilities involving improper synchronization and race conditions.

Attack Vector

The deadlock is triggered by legitimate system activity under memory pressure. There is no evidence of remote or authenticated attacker involvement. A local unprivileged workload that induces heavy VM reclaim on affected hardware can reproduce the freeze. The vulnerability is a reliability and availability defect rather than a code-execution primitive.

The fix replaces the blocking acquire with dma_resv_trylock(). If the trylock fails, the shrinker skips the buffer object rather than waiting, breaking the circular dependency. See the referenced kernel commits for the exact code change.

Detection Methods for CVE-2026-64100

Indicators of Compromise

Kernel log entries containing WARNING: possible circular locking dependency detected referencing msm_gem_shrinker_scan
System hangs or unresponsive kswapd0 kthread on Snapdragon-based Linux hosts
Stack traces showing drm_gem_lru_scan called from do_shrink_slab while fs_reclaim is held

Detection Strategies

Enable CONFIG_PROVE_LOCKING on test kernels to surface the circular dependency warning before deadlock
Correlate dmesg output with running kernel version and drm/msm module presence via lsmod
Monitor process state for kswapd stuck in D (uninterruptible sleep) exceeding expected thresholds

Monitoring Recommendations

Ingest kernel ring-buffer messages into centralized logging and alert on circular locking dependency strings
Track memory pressure metrics (/proc/pressure/memory) alongside GPU driver activity on affected devices
Verify installed kernel package versions against the fixed commit hashes across the fleet

How to Mitigate CVE-2026-64100

Immediate Actions Required

Update affected Linux kernels to a version containing the drm/msm: Fix shrinker deadlock patch
Inventory Snapdragon X1 and other Adreno-based Linux systems, prioritizing those running heavy memory workloads
Test the patched kernel with PROVE_LOCKING enabled to confirm the warning no longer occurs

Patch Information

The fix is available in the upstream Linux stable tree via commits 3392291fc509d8ad6e4ad90f15b0a193f721cbc9, 928788566c79046f71a211fc32c115400be76402, and 942968260e61d4a5d7552b20814b6277f9c553df. Distributions shipping affected kernels should backport these commits. See the kernel.org stable commit references for full patch content.

Workarounds

Unload the msm module on systems that do not require GPU acceleration, using modprobe -r msm
Reduce memory pressure by tuning vm.swappiness and vm.min_free_kbytes to lower the frequency of kswapd-driven shrinker invocations
Boot with drm.debug and lockdep disabled in production if the warning-only condition triggers watchdog resets

bash

# Verify kernel version and applied commits
uname -r
zcat /proc/config.gz | grep -E 'CONFIG_DRM_MSM|CONFIG_PROVE_LOCKING'

# Temporarily unload the MSM driver where feasible
sudo modprobe -r msm