Consider the following series of events for a device-mapper crypt target, test, holding an ext4 filesystem. These three commands swap out the crypt target's table with a new (dummy) table. This changes the encryption key to an invalid one. The device is suspended to prevent accesses:
# blockdev --flushbufs /dev/mapper/test
# dmsetup suspend test
# dmsetup reload -r --table "$newtable" test
Unfortunately, it's necessary to resume and then re-suspend the device in order to actually commit the table change (to move the table from the inactive slot to the live slot and clear the inactive table), so for a brief period of time, the device will be in a corrupt state (the live table has the wrong encryption key) yet is unsuspended (the reason -r is used above is to prevent catastrophic writes):
# dmsetup resume test
# dmsetup suspend --noflush test
# echo 3 > /proc/sys/vm/drop_caches
Caches are dropped so that any invalid data read and cached between the previous resume and suspend will not hang around. Later, the old table is restored. This makes the device writable:
# dmsetup reload --table "$oldtable" test
# dmsetup resume test
The only difference between the two tables is the key:
# echo $oldtable
0 65536 crypt aes-cbc-essiv:sha256 70f91902a1c1fcf7baaf4da03e852960 0 7:1 0
# echo $newtable
0 65536 crypt aes-cbc-essiv:sha256 00000000000000000000000000000000 0 7:1 0
Can this sequence cause any data corruption on test in any circumstances?
