CVE-2025-71181

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: remove spin_lock() in rust_shrink_free_page()<br /> <br /> When forward-porting Rust Binder to 6.18, I neglected to take commit<br /> fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope") into<br /> account, and apparently I did not end up running the shrinker callback<br /> when I sanity tested the driver before submission. This leads to crashes<br /> like the following:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.18.0-mainline-maybe-dirty #1 Tainted: G IO<br /> --------------------------------------------<br /> kswapd0/68 is trying to acquire lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: lock_list_lru_of_memcg+0x128/0x230<br /> <br /> but task is already holding lock:<br /> ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;l-&gt;lock);<br /> lock(&amp;l-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> May be due to missing lock nesting notation<br /> <br /> 3 locks held by kswapd0/68:<br /> #0: ffffffff90d2e260 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x597/0x1160<br /> #1: ffff956000fa18b0 (&amp;l-&gt;lock){+.+.}-{2:2}, at: rust_helper_spin_lock+0xd/0x20<br /> #2: ffffffff90cf3680 (rcu_read_lock){....}-{1:2}, at: lock_list_lru_of_memcg+0x2d/0x230<br /> <br /> To fix this, remove the spin_lock() call from rust_shrink_free_page().