Linux Kernel up to 6.18.18/6.19.8/7.0-rc3 set_notification_done deadlock

Summaryinfo

A vulnerability has been found in Linux Kernel up to 6.18.18/6.19.8/7.0-rc3 and classified as critical. This issue affects the function set_notification_done. Performing a manipulation results in deadlock. This vulnerability is known as CVE-2026-23400. Remote exploitation of the attack is possible. No exploit is available. The affected component should be upgraded.

Detailsinfo

A vulnerability classified as critical has been found in Linux Kernel up to 6.18.18/6.19.8/7.0-rc3. This affects the function set_notification_done. The manipulation with an unknown input leads to a deadlock vulnerability. CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock. This is going to have an impact on availability. The summary by CVE is:

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.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2026-23400 since 01/13/2026. The exploitability is told to be difficult. It is possible to initiate the attack remotely. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1499 for this issue.

The vulnerability scanner Nessus provides a plugin with the ID 304244 (Linux Distros Unpatched Vulnerability : CVE-2026-23400), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.18.19, 6.19.9 or 7.0-rc4 eliminates this vulnerability. Applying the patch dd109e3442817bc03ad1f3ffd541092f8c428141/3be72099067d2cd4a0e089696f19780f75b2b88a/2e303f0febb65a434040774b793ba8356698802b is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at CNNVD (CNNVD-202603-5883), Tenable (304244), EUVD (EUVD-2026-16993) and CERT Bund (WID-SEC-2026-0910). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Affected

• Open Source Linux Kernel

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5
• 6.19.6
• 6.19.7
• 6.19.8
• 7.0-rc1
• 7.0-rc2
• 7.0-rc3

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion