CVE-2025-71181

/// Technical description

In the Linux kernel, the following vulnerability has been resolved:

rust_binder: remove spin_lock() in rust_shrink_free_page()

When forward-porting Rust Binder to 6.18, I neglected to take commit

fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into

account, and apparently I did not end up running the shrinker callback

when I sanity tested the driver before submission. This leads to crashes

like the following:

============================================

WARNING: possible recursive locking detected

6.18.0-mainline-maybe-dirty #1 Tainted: G IO

--------------------------------------------

kswapd0/68 is trying to acquire lock:

ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230

but task is already holding lock:

ffff956000fa18b0 (&l->lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20

other info that might help us debug this:

Possible unsafe locking scenario:

CPU0

----

lock(&l->lock);

lock(&l->loc

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References