CVE-2026-23400

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: call set_notification_done() without proc lock<br /> <br /> Consider the following sequence of events on a death listener:<br /> 1. The remote process dies and sends a BR_DEAD_BINDER message.<br /> 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.<br /> 3. The local process then invokes the BC_DEAD_BINDER_DONE.<br /> Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a<br /> BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().<br /> <br /> However, this can result in a deadlock if the current thread is not a<br /> looper. This is because dead_binder_done() still holds the proc lock<br /> during set_notification_done(), which called push_work_if_looper().<br /> Normally, push_work_if_looper() takes the thread lock, which is fine to<br /> take under the proc lock. But if the current thread is not a looper,<br /> then it falls back to delivering the reply to the process work queue,<br /> which involves taking the proc lock. Since the proc lock is already<br /> held, this is a deadlock.<br /> <br /> Fix this by releasing the proc lock during set_notification_done(). It<br /> was not intentional that it was held during that function to begin with.<br /> <br /> I don&amp;#39;t think this ever happens in Android because BC_DEAD_BINDER_DONE<br /> is only invoked in response to BR_DEAD_BINDER messages, and the kernel<br /> always delivers BR_DEAD_BINDER to a looper. So there&amp;#39;s no scenario where<br /> Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.