Database/Container, Kubernetes & orchestration
Slurm: Incorrect access control leading to information disclosure across users' jobs
Impact
Incorrect access control leading to information disclosure across users' jobs
Who can reach it
Any user who can submit a job
What to do
Upgrade Slurm
Fleet impact
How widespread
Very common - Slurm is the default scheduler on HPC-style GPU clouds and on most bare-metal H100/GB200 clusters sold to AI labs
Cost to remediate
daemon-restart fleet-wide - SchedMD is explicit that the cluster stays vulnerable until *every* slurmdbd, slurmctld and slurmd has restarted, i.e. a coordinated restart across all compute nodes
Why it hits the whole fleet
Credential-handling flaw lets an unprivileged user impersonate SlurmUser and then run arbitrary processes as root; affects every Slurm release since 1.0.0, so one bug covers the whole scheduler estate
References
Related entries
- Slurm: Incorrect access control leading to privilege escalation and code executionCVE-2022-29501 · SlurmHigh
- Slurm: slurmd message-integrity bypass permits reuse of root-level authentication tokensCVE-2023-49935 · SlurmHigh
- Slurm: A user can modify their extended group list used by sbcast and open files with unauthorized permissionsCVE-2023-49938 · SlurmHigh
- Slurm: Race condition in message aggregation allows launching a process as another userCVE-2020-12693 · SlurmHigh
- Slurm: Improper message-integrity enforcement allows RPC traffic modificationCVE-2023-49933 · SlurmHigh
- Slurm: Filesystem race conditions allow gaining ownership of, overwriting, or deleting filesCVE-2023-41914 · SlurmHigh
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.