---

Introduction

In this post, we will break down CVE-2022-29502, a major vulnerability discovered in SchedMD Slurm versions 21.08.x through 20.11.x. Slurm is a widely used open-source workload manager designed for Linux clusters, found in big research labs, universities, and supercomputing sites across the world.

This vulnerability has a direct impact on the security of systems using affected Slurm versions — it allows a regular user to escalate their privileges inappropriately, which might lead to running commands as a different or even privileged user. Here, we'll explain what went wrong, how attackers could exploit it, and give you resources to patch your system.

What is CVE-2022-29502?

CVE-2022-29502 is an Incorrect Access Control flaw. In plain words, Slurm failed to properly check if a user is actually allowed to perform critical actions. Specifically, the problem exists in how Slurm daemon components (slurmctld and slurmd) and user commands interact.

If not fixed, an attacker on the same system could use this bug to run code or commands as another user. This is particularly risky on shared clusters, where research, confidential data, or regulated workloads may be running side by side.

Technical Details

The vulnerability is tied to insufficient verification of submitted job scripts and the user identities. When a job is submitted to the Slurm controller, certain parameters in the payload could be manipulated to impersonate other users or escalate privileges within the system.

To quote from the official advisory from SchedMD

> There was an incorrect handling of user authentication in Slurm prior to 21.08.8, which could allow an attacker to escalate privileges under certain conditions.

Slurm 20.11.x (before 20.11.9)

Note: Newer releases (21.08.8+, 20.11.9+) have patched this issue, so upgrade immediately if you are running older versions.

Here's a simplified step-by-step scenario demonstrating how an attacker might exploit CVE-2022-29502

1. User prepares a malicious job submission: By crafting a special job script or using specific command-line options, the attacker sets parameters to impersonate another user.
2. Job submission via sbatch or srun: The attacker submits the job to the Slurm controller (slurmctld).
3. Slurm fails to verify user identity properly: Due to the access control flaw, Slurm accepts the forged credentials or identity information within the job submission.

Imagine the following scenario

Attacker: Regular user alice  
Victim: Another user bob

The attacker constructs a job submission script that impersonates Bob using crafted payloads or fields in the job request packet. Slurm mishandles the check, and as a result, the job runs as Bob.

Proof-of-Concept (PoC) Snippet

While we won't publish full weaponized exploit scripts here, a basic illustration (with non-patched versions) might look like this:

# Pseudocode: Do NOT use in production
export USER=bob
sbatch --uid=bob myscript.sh

If the access control was broken, this would confuse Slurm into launching myscript.sh as Bob, even though Alice submitted it.

In patched versions, the --uid parameter and other user fields are strictly enforced and cross-checked, so only authorized changes can be made.

Step 1: Identify your Slurm version.

$ scontrol version
slurm 21.08.7

Step 2: Upgrade to the latest version.

Visit the Slurm Download Page and get at least version 21.08.8 or 20.11.9.

# On Red Hat-based systems:
sudo yum update slurm

# Or, manually install the updated package from source or your repository

Step 3: Restart Slurm services.

sudo systemctl restart slurmctld
sudo systemctl restart slurmd

Key References

- SchedMD Security Advisory
- NVD Entry: CVE-2022-29502
- Slurm Release Notes
- Upgrading Slurm Documentation

Conclusion

CVE-2022-29502 demonstrates how even critical software can miss subtle, yet potentially devastating, access control checks. If you are responsible for a Slurm cluster running one of the impacted versions, you must upgrade immediately. Leaving this unpatched could allow malicious users to disrupt workloads, steal data, or even take over sensitive computations.

Always keep your job schedulers and related infrastructure up to date, and keep an eye on announcements from SchedMD and system security feeds.

Timeline

Published on: 05/05/2022 17:15:00 UTC
Last modified on: 05/18/2022 11:15:00 UTC