LUKS header TOCTOU between validation and luksOpen #555

The disk setup logic in dstack/dstack-util/src/system_setup.rs checks whether a LUKS header exists and then separately opens the device, creating a TOCTOU window where the header state could change between the check and the open.

Root Cause

The LUKS2 disk encryption setup follows a validate-then-use pattern with a time gap between the two operations:

1. The LUKS header is backed up to tmpfs
2. The header is validated (checking for null cipher — CVE-2025-59054 mitigation)
3. cryptsetup luksOpen is called on the original device (not the validated copy)

Between steps 2 and 3, the on-disk header could be modified by a malicious host operator (who has direct access to the block device), replacing the validated header with a malicious one (e.g., null cipher).

Attack Path

1. CVM starts disk encryption setup
2. dstack backs up the LUKS header and validates it (no null cipher)
3. Malicious host operator modifies the on-disk LUKS header between validation and luksOpen
4. cryptsetup luksOpen uses the modified (malicious) header
5. The attacker could set a null cipher, causing data to be written unencrypted despite passing validation

Impact

Potential bypass of the CVE-2025-59054 null cipher check. A sophisticated host operator with precise timing could substitute a malicious LUKS header after validation but before use. The practical exploitability depends on the timing window and the host's ability to modify the block device while the CVM is accessing it.

Suggested Fix

Use the validated header copy for luksOpen instead of the original device:

// Use --header flag to specify the validated header
cryptsetup luksOpen --header /tmp/validated-header.bin /dev/vdb encrypted

Or perform validation and open atomically using the backed-up header.

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.