CVE-2016-10030

What it actually does

The _prolog_error function in slurmd/req.c allows a local user to specify and control an arbitrary file on the system when a Prolog script returns a non-zero exit code, enabling file overwrite or control under specific conditions.

Why it matters to the business

Organizations running HPC or cluster workloads with custom Prolog scripts face risk of unauthorized file modification on compute nodes, potentially leading to job disruption, data tampering, or node compromise if scripts are not hardened.

How an attack unfolds

An attacker submits a job that triggers or anticipates a Prolog script failure on a compute node; the slurmd daemon then mishandles the error reporting path, allowing the attacker to direct the daemon to write or control a chosen file instead of the intended error handling.

How to fix it

Upgrade Slurm to a fixed version such as the commit 92362a92fffe60187df61f99ab11c249d44120ee or later releases (15.08.13+, 16.05.7+, 17.02.0-pre4+); alternatively disable Prolog scripts or modify them to always return success and use scontrol to mark nodes down.

How to confirm the fix worked

Confirm Slurm version is at or above the listed fixed commits or releases; test by submitting jobs that would previously trigger Prolog failures and verify no arbitrary file control occurs; review Prolog configuration for the recommended workarounds.

Typical attack path

1. Identify or craft a job submission that causes a Prolog script to exit non-zero
2. Submit the job to a Slurm cluster with an active Prolog configuration
3. Trigger the error path in slurmd/req.c
4. Specify target file path via the vulnerable error reporting mechanism
5. Achieve control or overwrite of the arbitrary file

How to detect it

Review slurmd logs for unusual Prolog error handling or file access attempts; inspect job submission logs for patterns of deliberate Prolog failures; check system file timestamps and ownership changes on critical configuration or data files following job runs.

What your security team should do

• Prioritize upgrade of all Slurm installations to patched versions within maintenance windows
• Audit and harden or disable Prolog scripts as a compensating control
• Monitor for jobs causing repeated Prolog failures as a potential indicator