CVE-2026-89329

What it actually does

A local client that can open the multipathd UNIX-domain control socket can stall the daemon’s listener thread by sending valid control commands and then stopping consumption of replies. The blocked listener causes subsequent legitimate IPC to hang or time out, denying multipath control-plane operations on the host. The flaw does not enable privilege escalation, code execution, or any loss of confidentiality or integrity.

Why it matters to the business

Storage path management and failover on Linux hosts running multipathd can become unresponsive, delaying recovery of SAN- or multipath-backed disks and the applications that depend on them. Impact is availability-only and requires local access, so this is operational downtime risk rather than a data-breach scenario. The issue is not in CISA KEV, is not tied to ransomware, has no known public exploit (maturity None), and EPSS remains very low and flat (~0.0016 over 30 days). About a month after publication, urgency is a normal patch cycle except on shared or multi-tenant systems where untrusted local users can reach the control socket.

How an attack unfolds

An attacker who already has a local session on a host running multipathd connects to the daemon’s UNIX control socket, which typical deployments do not treat as a privileged interface. They issue otherwise-valid control-plane commands and then cease reading the daemon’s replies. The listener thread blocks waiting for the client to drain responses, so other IPC clients—including administrative tools and path-management workflows—hang or time out until the stuck connection is closed or multipathd is restarted. No remote exposure, authentication bypass, or payload execution is involved, and no named threat actors are associated with this CVE.

How to fix it

Install the device-mapper-multipath / multipathd update from your Linux distribution’s security advisory and restart the multipathd service. No specific upstream or per-package fixed versions were supplied with this record, so treat vendor/distro advisories as authoritative. Until a patch is applied, restrict ownership and mode of the control socket so only trusted administrative users and service accounts can connect, and use systemd/unit sandboxing to keep unprivileged local users off the socket. Network firewalls do not mitigate this local IPC issue.

How to confirm the fix worked

Confirm the installed multipathd / device-mapper-multipath package version matches the patched release in your distribution advisory. Inspect control-socket ownership and permissions under the runtime directory (commonly /run or /var/run) and verify untrusted local users cannot open it. After upgrade and service restart, confirm administrative IPC completes without hang or timeout and that path maps still enumerate correctly.

Typical attack path

1. Obtain local access to a Linux host where multipathd is running
2. Connect to the multipathd UNIX-domain control socket as an unprivileged local user
3. Send valid control-plane commands over that socket
4. Stop reading replies so the listener thread blocks
5. Leave legitimate multipath IPC clients hung or timed out until the connection is cleared or the daemon is restarted

How to detect it

This is a local availability attack without malware or known threat-actor tooling, so hunt operational artifacts rather than dropped binaries. Review journald/syslog for multipathd becoming unresponsive, IPC timeouts, or control-socket errors around storage-path incidents. Check whether unprivileged processes hold the multipathd UNIX socket open and are not consuming data; correlate with timed-out multipath administrative commands, a running but IPC-unresponsive multipathd.service, and local login records identifying who was on the host. No ransomware families or named APT groups are linked to this CVE.

• /run/multipathd.sock
• /var/run/multipathd.sock
• /usr/sbin/multipathd
• multipathd.service

What your security team should do

• Inventory hosts running multipathd, prioritizing SAN/multipath and multi-tenant Linux servers where unprivileged local users exist
• Patch and restart multipathd on those hosts per the distribution advisory; there is no CISA KEV due date, so schedule with other medium local-DoS fixes unless the host is on a critical storage path
• Harden UNIX-socket permissions and service sandboxing so only trusted accounts can talk to the control socket
• Watch for hung multipath IPC and unexpected local connectors to the control socket until patches are fully rolled out
• Do not treat this as an emergency ransomware or remote-RCE event: EPSS is negligible, exploit maturity is None, and impact is local availability only