Description

A flaw was found in `multipathd`. A local attacker with access to the `multipathd` UNIX control socket can exploit this vulnerability by sending valid commands and then ceasing to read replies. This action can cause the `multipathd` listener thread to block, leading to a Denial of Service (DoS) where legitimate Inter-Process Communication (IPC) operations may hang or time out. This issue does not result in privilege escalation, arbitrary code execution, or impact data confidentiality or integrity.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-09-11T19:17:47.710Z",
  "pubdate": "2026-09-11T19:17:47.710Z",
  "executiveSummary": "A denial-of-service (DoS) vulnerability exists in the multipathd daemon, specifically concerning the handling of the UNIX control socket interface.\nThe vulnerability occurs due to improper management of client-server IPC flow control, where an attacker can induce a thread block by intentionally stalling the consumption of socket response data.\nThe vulnerability affects local users with access to the multipathd UNIX domain socket.\nSuccessful exploitation results in the unresponsive state of the listener thread, effectively preventing legitimate IPC operations and administrative commands from being processed by multipathd.\nThis issue does not grant the attacker additional privileges, nor does it allow for arbitrary code execution or data exfiltration.\nThe primary risk is service instability for system components relying on multipathd for device management and synchronization.\nExploitation requires local access to the system and the ability to interface with the multipathd control socket, which typically restricts the exploit vector to authenticated local users or processes.",
  "technicalDetails": "The vulnerability originates in the multipathd communication model, which utilizes a UNIX control socket to facilitate interaction with client applications such as multipathd commands. The daemon's architecture employs a listener thread responsible for accepting and servicing these IPC requests.\nThe root cause of this denial-of-service condition is a resource exhaustion or flow-control deficiency within the socket handling logic. When a client establishes a connection to the multipathd UNIX socket and issues valid commands, the server generates a response. If the client intentionally ceases to read the returned data from the socket buffer, the underlying kernel socket buffer eventually reaches its capacity.\nOnce the buffer is full, the write operation performed by the multipathd listener thread blocks as it attempts to send the response. Because the daemon lacks an asynchronous timeout mechanism or non-blocking I/O flow control for these socket operations, the entire listener thread hangs while waiting for the client to resume consumption of the buffer contents.\nThe attack flow follows a deterministic sequence: First, the attacker initiates a connection to the multipathd UNIX domain socket. Second, the attacker transmits one or more valid administrative commands to the daemon. Third, the attacker deliberately stops reading the socket responses. Finally, the server-side write operation stalls due to the saturated socket buffer. This keeps the thread in a blocked state, rendering the IPC interface unavailable for all other legitimate system processes, causing time-outs in administrative operations and potentially impacting automated storage management tasks.\nThe vulnerability is restricted to the local environment, as the UNIX domain socket is inherently local to the host. No network-based exposure is involved. Furthermore, the impact is strictly limited to availability; the flaw does not facilitate memory corruption, bypass kernel protections, or enable privilege escalation."
}