CVE-2026-120749 in Red Hat
Summary
by MITRE • 11/06/2026
A flaw was found in D-Bus. With a privileged Monitoring client attached (for example dbus-monitor or busctl monitor), an unprivileged local user can cause dbus-daemon to abort if a driver-originated broadcast such as NameOwnerChanged or ActivatableServicesChanged cannot be delivered to a recipient (for example due to a deny rule or an exceeded outgoing message queue). Driver broadcasts still use serial 0; when delivery fails, composing the monitor error reply asserts reply_serial != 0 and aborts the daemon. This is an incomplete fix for CVE-2023-34969, which only assigned serials for driver messages sent to a single recipient. On the well-known system bus this is a denial of service.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in D-Bus represents a critical flaw within the message bus daemon's handling of privileged monitoring clients and broadcast signals. Specifically, when an unprivileged local user triggers a driver-originated broadcast signal, such as NameOwnerChanged or ActivatableServicesChanged, the system may encounter delivery failures due to access control deny rules or exhausted outgoing message queues. In these scenarios, D-Bus attempts to compose an error reply for attached privileged monitoring clients like dbus-monitor or busctl monitor. The technical root cause lies in a logic error where the daemon asserts that the reply serial must be non-zero; however, driver broadcasts inherently utilize serial zero because they are not directed at specific recipients but rather broadcasted system-wide. This assertion failure causes an immediate abort of the dbus-daemon process, leading to a complete service interruption for all connected clients on the bus.
This issue is classified as an incomplete fix for CVE-2023-34969, which previously addressed similar denial-of-service conditions by assigning unique serials only for driver messages sent to single recipients. The current flaw exposes that broadcast scenarios were not adequately covered in prior remediation efforts. From a classification perspective, this vulnerability aligns with CWE-835, specifically the loop or iteration involving an uncontrolled resource consumption leading to a crash, and more accurately reflects CWE-20, Improper Input Validation, as the daemon fails to properly validate the serial number context before asserting its validity against zero-value broadcasts. The attack vector is local and requires no authentication for the initial trigger if the user can generate sufficient broadcast traffic or manipulate bus state to cause delivery failures, making it accessible to any unprivileged account on the system.
The operational impact of this vulnerability is a severe denial of service affecting the entire D-Bus infrastructure on the affected host. Since dbus-daemon acts as the central communication backbone for many Linux desktop environments and system services, its termination disrupts inter-process communication across multiple applications. This can result in application crashes, loss of user session functionality, or failure of critical system services that rely on bus notifications. The impact is particularly acute because it does not require privilege escalation to exploit; any local user with standard permissions can trigger the condition by inducing conditions where broadcast messages cannot be delivered to monitoring clients, thereby crashing the daemon and effectively halting normal system operations dependent on D-Bus messaging.
Mitigation strategies should focus on applying vendor-provided patches that correct the assertion logic within dbus-daemon to handle zero-serial broadcasts appropriately without aborting. Administrators can also implement temporary workarounds by restricting access to privileged monitoring tools or configuring firewall-like rules via DBus policy files to limit which users can attach monitors, thereby reducing the attack surface. Additionally, deploying intrusion detection systems that monitor for abnormal termination of dbus-daemon processes may help in identifying active exploitation attempts. Long-term remediation requires ensuring all D-Bus components are updated to versions where both single-recipient and broadcast scenarios are handled with robust error recovery mechanisms rather than fatal assertions, aligning with secure coding practices recommended by industry standards such as the OWASP Secure Coding Practices Guide for handling unexpected input states in system daemons.