CVE-2026-89329: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-89329 is a Denial of Service vulnerability in multipathd (device-mapper-multipath) classified as a local DoS via blocking IPC send operations. A local attacker with access to the multipathd UNIX control socket can send valid commands and then stop reading replies, causing the listener thread to block and legitimate IPC operations to hang or time out. The vulnerability was reported on 2026-05-11 and publicly disclosed on 2026-09-11. Affected products include device-mapper-multipath on Red Hat Enterprise Linux and OpenShift (ose-rhel-coreos-8/9). It carries a CVSS v3.1 base score of 6.2 (Medium) (Red Hat CVE, Red Hat Bugzilla).

The root cause is CWE-1322 (Use of Blocking Code in Single-threaded, Non-blocking Context). In multipathd/uxlsnr.c, accepted client sockets are left in blocking mode, and the reply path uses blocking send() calls in the CLT_SEND state. A local attacker connects to the UNIX control socket (world-writable by default), sends valid commands such as list daemon, and deliberately never reads the replies. Once the kernel send buffer fills, the listener thread blocks in send(), stalling IPC servicing for all other clients. Non-root clients are restricted to list commands, but these still generate replies sufficient to trigger the condition. A proposed fix involves setting accepted sockets to non-blocking mode (O_NONBLOCK) and adding POLLOUT checks before sending, along with using MSG_DONTWAIT in send() calls (Red Hat Bugzilla, Red Hat CVE).

Exploitation results in a Denial of Service affecting the availability of the multipathd IPC control interface, causing legitimate IPC operations to hang or time out. There is no impact on confidentiality or integrity, and no privilege escalation or arbitrary code execution is possible. The effect is limited to the daemon's control interface rather than full system compromise, but in environments relying on multipathd for storage path management, disruption of the IPC listener could impair storage multipath operations (Red Hat CVE, Red Hat Bugzilla).

No public proof-of-concept exploit has been released, and there is no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog. The attack requires local access to the multipathd UNIX control socket, which is world-writable by default, making it practically reachable by unprivileged local users in default configurations without requiring any privileges. The NVD SSVC assessment classifies exploitation as "none" and the attack as not automatable (Red Hat CVE, Red Hat Bugzilla).

1. Reconnaissance: Confirm that multipathd is running on the target system and that the UNIX control socket (typically /run/multipathd.socket) is accessible to the local user account.
2. Connect to the control socket: Open a UNIX stream socket connection to /run/multipathd.socket from an unprivileged local account.
3. Send valid IPC commands: Transmit a valid command frame (e.g., list daemon\x00) prefixed with a length field packed as a 64-bit unsigned integer, as expected by the multipathd IPC protocol.
4. Withhold reply reads: Deliberately refrain from reading any data returned by multipathd on the connection, allowing the server-side send buffer to accumulate unread data.
5. Saturate the send buffer: Repeatedly send additional valid commands on the same connection without reading replies until the kernel socket send buffer is exhausted and multipathd's send() call blocks.
6. Observe DoS: From a separate terminal, issue a normal IPC command to multipathd and observe that it hangs or times out, confirming the listener thread is blocked (Red Hat Bugzilla).

• Process: multipathd process appearing unresponsive or consuming no CPU while legitimate IPC clients hang indefinitely waiting for responses.
• Logs: System logs or multipathd logs showing IPC timeout errors or hung client connections; absence of expected multipathd IPC responses to administrative commands.
• Network/Socket: Persistent open connections to /run/multipathd.socket from unexpected local processes or user accounts that are not reading data (detectable via ss -xp or lsof).
• Application Behavior: Storage management tools or scripts that rely on multipathd IPC (e.g., multipath -l) hanging or timing out without explanation (Red Hat Bugzilla).

The primary workaround is to restrict access to the multipathd UNIX control socket so that only trusted administrators can connect, preventing unprivileged local users from reaching the control interface. This can be achieved by tightening filesystem permissions on the socket or enforcing access controls (e.g., via SELinux policy or group membership). A patch has been tracked in Red Hat Bugzilla (Bug 2470013) that sets accepted client sockets to non-blocking mode and adds POLLOUT checks before sending; users should apply the fix once a released package update becomes available. Until a patched package is released, ensure that only trusted administrators have local access to systems running multipathd (Red Hat CVE, Red Hat Bugzilla).

The vulnerability was discovered by AISLE Research in partnership with Red Hat and reported through Red Hat's coordinated disclosure process. Red Hat's Product Security team classified the impact as Moderate, noting that while the condition is practically reachable in default local IPC exposure scenarios, it is limited to a local DoS with no code execution or data exposure risk. No significant broader media coverage or notable community commentary has been identified beyond standard vulnerability database aggregation (Red Hat CVE, Red Hat Bugzilla).