CVE-2026-23400
Received Received - Intake
Deadlock Vulnerability in Linux Kernel rust_binder Due to Proc Lock Misuse

Publication date: 2026-03-29

Last updated on: 2026-04-24

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-29
Last Modified
2026-04-24
Generated
2026-06-16
AI Q&A
2026-03-29
EPSS Evaluated
2026-06-15
NVD
CVE-2026-23400
EUVD
EUVD-2026-16993
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.18
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 6.18.1 (inc) to 6.18.19 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.9 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-667 The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's rust_binder component related to handling death notifications of remote processes.

When a remote process dies, a sequence of commands is triggered: the remote process sends a BR_DEAD_BINDER message, the local process calls BC_CLEAR_DEATH_NOTIFICATION, and then BC_DEAD_BINDER_DONE.

The kernel replies to BC_DEAD_BINDER_DONE using push_work_if_looper(), but if the current thread is not a looper, a deadlock can occur because the proc lock is held during set_notification_done(), which calls push_work_if_looper().

Normally, push_work_if_looper() takes the thread lock under the proc lock, which is safe. However, if the thread is not a looper, push_work_if_looper() tries to take the proc lock again, causing a deadlock since the proc lock is already held.

The fix was to release the proc lock during set_notification_done() to prevent this deadlock.

This issue likely does not occur in Android because BC_DEAD_BINDER_DONE is only called on looper threads.

Impact Analysis

This vulnerability can cause a deadlock in the Linux kernel when handling death notifications of remote processes if the current thread is not a looper.

A deadlock means that the affected thread will be stuck waiting indefinitely, potentially causing the system or affected processes to hang or become unresponsive.

This can impact system stability and reliability, especially in environments where non-looper threads might invoke BC_DEAD_BINDER_DONE.

However, it is noted that this scenario likely does not happen in Android systems, reducing the impact in that context.

Mitigation Strategies

The vulnerability is resolved by releasing the proc lock during the set_notification_done() function in the Linux kernel. Immediate mitigation involves updating the Linux kernel to a version where this fix is applied.

Since the issue is related to a deadlock caused by holding the proc lock during set_notification_done(), ensuring your system runs the patched kernel version will prevent this deadlock scenario.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-23400. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart