There is a multi-step attack on LUKS2 format by orchestrating LUKS2 reencryption metadata in existing LUKS2 header. An attacker is able to trigger permanent data decryption (ciphertext->plaintext transformation) on part of data device on next LUKS2 device activation. Attacker does _not_ have to know passphrase or decrypted volume encryption key. An attacker who can temporarily get physical access to an encrypted device (such as a flash drive encrypted with the LUKS2 format), could use this flaw in such a scenario : - secretly get the device and modify it with specially crafted headers - on subsequent decryption by a regular user, the code would "recover" the data, incidentally rewriting part of it in plain text - the attacker would then need to get access to the device again, in order to read the plaintext data - the attacker may optionally modify the plaintext, and/or modify again the header such that it would get re-encrypted again the next time the device is open. This would affect the integrity of the data and make the attack mostly silent (almost no trace of the attack on the disk) cryptsetup versions older than 2.2.0 are not affected by this, because they do not support online LUKS2 reencryption.
Upstream fix : https://gitlab.com/cryptsetup/cryptsetup/-/commit/0113ac2d889c5322659ad0596d4cfc6da53e356c
Created cryptsetup tracking bugs for this issue: Affects: fedora-all [bug 2040194]
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:0370 https://access.redhat.com/errata/RHSA-2022:0370
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-4122