Summary
A malicious host may provide a crafted LUKS2 data volume to a Dstack CVM for use as the /data mount. The guest will open the volume and write secret data using a volume key known to the attacker, causing disclosure of Wireguard keys and other secret information. The attacker can also pre-load data on the device, which could potentially compromise guest execution.
LUKS2 volume metadata is not authenticated and supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume:
- Opens (cryptsetup open) without error using any passphrase or token
- Records all writes in plaintext (or ciphertext with an attacker-known key)
- Contains arbitrary data chosen by the attacker
Details
The Dstack CVM image uses LUKS2-encrypted volumes for persistent storage. When resuming an already-initialized guest, the VM attempts to open a LUKS volume. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the availability of null algorithms in the cryptsetup, it is possible that the opened volume is not encrypted at all.
Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field.
A LUKS2 disk encrypted with a master key, which is in turn encrypted with user passwords stored in some number of keyslots. By creating a malicious disk which sets the keyslot encryption algorithm to ”crypto_null-ecb”, an attacker can construct a disk such that keyslot decryption does not depend in any way on the enclave-held secret data. When a confidential guest opens such a device using cryptsetup open, the mapped disk is created without error, and any further writes to the disk are encrypted using an attacker-controlled key.
While null keyslot algorithms will be disallowed in cryptsetup version 2.8.1, null volume ciphers will still be enabled. An attacker can use a previously-seen keyslot and associate a null-encrypted segment in order to force plaintext writes.
The volume encryption algorithm is also configurable. By taking an existing LUKS header and modifying the volume encryption cipher to cipher_null-ecb, an attacker can make a disk that opens correctly with the existing key but writes to disk in plaintext.
Detection
Inspect LUKS2 headers for any use of a cipher with the name: "cipher_null-ecb", for example, using this command:
sudo cryptsetup luksDump --dump-json-metadata $DEVICE | grep cipher_null-ecb
Recommendations
A partial fix is scheduled for release in cryptsetup version 2.8.1 this week, disabling null ciphers in keyslots when the user passphrase is nonempty. Guests should migrate to cryptsetup 2.8.1 when available. However, this does not mitigate the issue of null ciphers for volume encryption.
As a short term solution, LUKS disk metadata can be measured into RTMRs by using detached header mode. For example:
# Store header in confidential RAM fs
cryptsetup luksHeaderBackup --header-backup-file /tmp/luks_header $BLOCK_DEVICE;
# Measure the result into RTMRs
cryptsetup luksDump --type luks2 --dump-json-metadata /tmp/luks_header | jq 'reduce (paths(scalars) | select(.[-1]=="salt" or .[-1]=="digest")) as $p (.; setpath($p; ""))' > measurement.json
# Fetch keys from KMS after measurement
...
# Open using tmpfs header to avoid TOCTOU
cryptsetup open --type luks2 --header /tmp/luks_header $BLOCK_DEVICE --key-file=enc_key.txt
As a longer term solution, consider adding a cryptographic MAC that covers the full header of storage devices, in order to ensure that tampering with any field is detected.
Coordination & timeline
We are coordinating disclosure with several vendors of confidential computing solutions who are using LUKS2-based disk encryption. Please do not disclose details of this issue publicly until the embargo date.
Discovery: 2025-08-07.
Cryptsetup vendor notification: 2025-08-15.
Coordinated public disclosure target: 2025-10-01 15:00 UTC.
We will share a minimal PoC LUKS2 header if requested.
tjade273 Reporter
Summary
A malicious host may provide a crafted LUKS2 data volume to a Dstack CVM for use as the
/datamount. The guest will open the volume and write secret data using a volume key known to the attacker, causing disclosure of Wireguard keys and other secret information. The attacker can also pre-load data on the device, which could potentially compromise guest execution.LUKS2 volume metadata is not authenticated and supports null key-encryption algorithms, allowing an attacker to create a volume such that the volume:
Details
The Dstack CVM image uses LUKS2-encrypted volumes for persistent storage. When resuming an already-initialized guest, the VM attempts to open a LUKS volume. If the VM is successful in opening the partition with the disk encryption key, it treats the volume as confidential. However, due to the availability of null algorithms in the cryptsetup, it is possible that the opened volume is not encrypted at all.
Cryptsetup prior to version 2.8.1 does not report an error when processing LUKS2-formatted disks that use the cipher_null-ecb algorithm in the keyslot encryption field.
A LUKS2 disk encrypted with a master key, which is in turn encrypted with user passwords stored in some number of keyslots. By creating a malicious disk which sets the keyslot encryption algorithm to ”crypto_null-ecb”, an attacker can construct a disk such that keyslot decryption does not depend in any way on the enclave-held secret data. When a confidential guest opens such a device using cryptsetup open, the mapped disk is created without error, and any further writes to the disk are encrypted using an attacker-controlled key.
While null keyslot algorithms will be disallowed in cryptsetup version 2.8.1, null volume ciphers will still be enabled. An attacker can use a previously-seen keyslot and associate a null-encrypted segment in order to force plaintext writes.
The volume encryption algorithm is also configurable. By taking an existing LUKS header and modifying the volume encryption cipher to
cipher_null-ecb, an attacker can make a disk that opens correctly with the existing key but writes to disk in plaintext.Detection
Inspect LUKS2 headers for any use of a cipher with the name: "cipher_null-ecb", for example, using this command:
Recommendations
A partial fix is scheduled for release in cryptsetup version 2.8.1 this week, disabling null ciphers in keyslots when the user passphrase is nonempty. Guests should migrate to cryptsetup 2.8.1 when available. However, this does not mitigate the issue of null ciphers for volume encryption.
As a short term solution, LUKS disk metadata can be measured into RTMRs by using detached header mode. For example:
As a longer term solution, consider adding a cryptographic MAC that covers the full header of storage devices, in order to ensure that tampering with any field is detected.
Coordination & timeline
We are coordinating disclosure with several vendors of confidential computing solutions who are using LUKS2-based disk encryption. Please do not disclose details of this issue publicly until the embargo date.
Discovery: 2025-08-07.
Cryptsetup vendor notification: 2025-08-15.
Coordinated public disclosure target: 2025-10-01 15:00 UTC.
We will share a minimal PoC LUKS2 header if requested.