Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-11-06T07:17:06.153Z",
  "pubdate": "2026-11-06T07:17:06.153Z",
  "executiveSummary": "A vulnerability exists in dbus-daemon, the message bus system, where an unprivileged local user can trigger an abort of the daemon, leading to a Denial of Service (DoS).\nThis flaw is an incomplete mitigation for CVE-2023-34969, specifically regarding the handling of serial numbers for driver-originated broadcast messages.\nThe vulnerability occurs when a privileged monitoring client is attached to the system bus and a driver-originated broadcast (e.g., NameOwnerChanged or ActivatableServicesChanged) fails to reach a specific recipient due to security restrictions or resource exhaustion (exceeded message queues).\nUnder these conditions, the daemon attempts to compose a monitor error reply. Because the driver broadcast maintains a serial number of 0, and the error reply composition code asserts that reply_serial must not be 0, the process triggers an abort, effectively crashing the D-Bus service.\nThis vulnerability is critical for the system bus, as it allows any unprivileged local user to disrupt system-wide inter-process communication, impacting all dependent services and system stability.\nExploitation requires the presence of an active, privileged monitoring client on the system.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of serial numbers for D-Bus driver-originated broadcast messages. In the D-Bus protocol, serial 0 is reserved and typically indicates an invalid or uninitialized sequence number. Historically, driver-originated broadcasts utilize serial 0.\nWhen a privileged monitoring client (e.g., dbus-monitor or busctl monitor) is attached to the bus, it observes message traffic. If a driver-originated broadcast cannot be delivered to a recipient—perhaps due to a configured deny rule or because the recipient's outgoing message queue has reached its maximum capacity—the dbus-daemon attempts to generate an error reply to inform the monitor of the failure.\nThe underlying issue is that the code responsible for composing this monitor error reply enforces an assertion: reply_serial != 0. Because the failing driver broadcast retains serial 0, the logic fails to account for the context of broadcast messages.\nThe attack flow proceeds as follows: First, an attacker ensures a privileged monitoring client is active on the system bus. Second, the attacker triggers an event that forces the dbus-daemon to broadcast a driver-level signal, such as 'NameOwnerChanged' or 'ActivatableServicesChanged'. Third, the attacker manipulates conditions to ensure this delivery fails for a specific recipient, such as saturating the recipient's message queue or utilizing known bus policy restrictions.\nUpon delivery failure, the dbus-daemon logic attempts to construct a notification of the failure for the monitor. The code path encounters the hard-coded assertion requiring a non-zero serial number. Because the source message possesses a serial of 0, the assertion fails, and the process calls abort(), resulting in an immediate termination of the daemon.\nThis vulnerability is classified as an incomplete fix for CVE-2023-34969, which previously addressed serial assignment for unicast driver messages but failed to adequately address the logic requirements for broadcast messages on the system bus. This flaw is local in nature, requiring no specific network exposure, but it leverages the standard, expected behavior of the D-Bus daemon to cause a total loss of availability for the message bus."
}