CVE-2025-71181: Linux Kernel Race Condition Vulnerability

CVE-2025-71181 Overview

A deadlock vulnerability exists in the Linux kernel's Rust Binder driver (rust_binder) within the rust_shrink_free_page() function. The vulnerability was introduced during the forward-port of Rust Binder to kernel version 6.18, where commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") was not properly accounted for, resulting in recursive locking that can cause system crashes and denial of service.

Critical Impact

This vulnerability can cause kernel deadlocks and system crashes when the memory shrinker callback is invoked, potentially leading to denial of service conditions on affected Linux systems running the Rust Binder driver.

Affected Products

• Linux kernel with Rust Binder driver (version 6.18+)
• Systems utilizing the rust_binder module with memory cgroup support
• Kernel configurations with list_lru shrinker callbacks enabled

Discovery Timeline

• 2026-01-31 - CVE CVE-2025-71181 published to NVD
• 2026-02-03 - Last updated in NVD database

Technical Details for CVE-2025-71181

Vulnerability Analysis

The vulnerability stems from an improper locking sequence in the Rust Binder shrinker callback implementation. When the memory reclaim process (kswapd) attempts to free pages through the shrinker interface, the rust_shrink_free_page() function acquires a spinlock (&l->lock) via rust_helper_spin_lock(). Subsequently, when lock_list_lru_of_memcg() is called as part of the reclaim operation, it attempts to acquire the same lock that is already held by the current thread.

This creates a classic deadlock scenario where a single CPU attempts to acquire a lock it already holds:

CPU0
----
lock(&l->lock);      // Acquired in rust_shrink_free_page()
lock(&l->lock);      // Attempted again in lock_list_lru_of_memcg()

*** DEADLOCK ***

The issue manifests when the kernel's memory reclaimer invokes the shrinker callback, which is a critical path for memory management under memory pressure conditions.

Root Cause

The root cause is the failure to account for changes introduced in commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") during the forward-port of Rust Binder to kernel 6.18. The original implementation included an explicit spin_lock() call in rust_shrink_free_page(), which became problematic when the list_lru subsystem's locking semantics changed to per-cgroup scope. The redundant lock acquisition creates the recursive locking condition that triggers the deadlock.

Attack Vector

The attack vector for this vulnerability is through local system conditions that trigger memory pressure. When the kernel's memory management subsystem initiates reclaim operations (via kswapd or direct reclaim paths), the vulnerable code path is exercised. An attacker with local access could potentially trigger this condition by:

1. Creating memory pressure conditions that force the kernel to invoke shrinker callbacks
2. Exercising code paths that utilize the Rust Binder driver's page allocation
3. Triggering the fs_reclaim context that leads to the shrinker being invoked

While this requires local access and specific conditions, the resulting system crash can cause denial of service. The vulnerability does not appear to allow arbitrary code execution or privilege escalation.

Detection Methods for CVE-2025-71181

Indicators of Compromise

• Kernel warning messages containing "possible recursive locking detected" referencing &l->lock
• System crashes or hangs associated with kswapd process activity
• Kernel panic or deadlock events occurring during memory reclaim operations
• Dmesg logs showing lock acquisition failures in rust_helper_spin_lock or lock_list_lru_of_memcg

Detection Strategies

• Monitor kernel logs for recursive locking warnings mentioning rust_shrink_free_page() or rust_binder
• Configure kernel lockdep debugging to detect deadlock scenarios during testing
• Implement system monitoring for unexpected kswapd process behavior or elevated CPU usage
• Review system stability reports for crashes correlated with memory pressure events

Monitoring Recommendations

• Enable kernel lockdep (CONFIG_PROVE_LOCKING) in development and testing environments to catch locking violations
• Set up automated kernel log monitoring for deadlock-related warnings
• Monitor system uptime and stability metrics on systems running the Rust Binder driver
• Implement alerting on kernel panic events that reference memory management subsystems

How to Mitigate CVE-2025-71181

Immediate Actions Required

• Apply the kernel patches referenced in commits 30a98c97f7874031f2e1de19c777ce011143cba4 or 361e0ff456a8daf9753c18030533256e4133ce7a
• Temporarily disable or avoid using the Rust Binder driver if patches cannot be immediately applied
• Monitor affected systems for signs of deadlock or instability
• Plan kernel upgrade to a version containing the fix

Patch Information

The fix involves removing the explicit spin_lock() call from the rust_shrink_free_page() function, as the lock is already managed by the list_lru subsystem. Official patches are available through the Linux kernel stable tree:

• Kernel Git Commit 30a98c97f787
• Kernel Git Commit 361e0ff456a8

Workarounds

• Disable the Rust Binder driver module if not required for system operation
• Reduce memory pressure on affected systems to minimize shrinker callback invocations
• Consider using alternative binder implementations until the patch can be applied
• Implement system restarts as a recovery mechanism if deadlocks occur

# Configuration example
# Disable the rust_binder module if not in use
echo "blacklist rust_binder" >> /etc/modprobe.d/blacklist-rust-binder.conf

# Verify module is not loaded
lsmod | grep rust_binder

# If loaded, remove the module (requires reboot if in use)
modprobe -r rust_binder 2>/dev/null || echo "Module in use - reboot required"