cbcvebase.
CVE-2026-23400
published 2026-03-29

CVE-2026-23400: In the Linux kernel, the following vulnerability has been resolved: rust_binder: call set_notification_done() without proc lock Consider the following sequence…

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

Affected

12 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.19.10-1 (forky)linux 6.19.10-1 (forky)
linuxlinux——
linuxlinux>= eafedbc7c050c44744fbdf80bdf3315e860b7513 < dd109e3442817bc03ad1f3ffd541092f8c428141dd109e3442817bc03ad1f3ffd541092f8c428141
linuxlinux>= eafedbc7c050c44744fbdf80bdf3315e860b7513 < 3be72099067d2cd4a0e089696f19780f75b2b88a3be72099067d2cd4a0e089696f19780f75b2b88a
linuxlinux>= eafedbc7c050c44744fbdf80bdf3315e860b7513 < 2e303f0febb65a434040774b793ba8356698802b2e303f0febb65a434040774b793ba8356698802b
linuxlinux_kernel——
linuxlinux_kernel——
linuxlinux_kernel>= 0 < 6.19.10-16.19.10-1
linuxlinux_kernel>= 6.18.0 < 6.18.196.18.19
linuxlinux_kernel>= 6.18.1 < 6.18.196.18.19
linuxlinux_kernel>= 6.19 < 6.19.96.19.9
linuxlinux_kernel>= 6.19.0 < 6.19.96.19.9
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.