Hi, there's unfortunate and quite nasty bug in IV initialization when key is being passed via kernel keyring service. We erase internal key copy too soon and we pass wrong key to IV initialization routines. Affected IVs I reproduced [1] the bug with are: 'essiv' and 'tcw'. I don't have a test yet for 'lmk', but it's probably also affected. Users probably won't notice the bug if they don't mix loading keys via keyring service and via classical hexbyte representation. But doing so and using any affected IV will lead to data corruption. The good news is keyring service is not used with LUKS1 devices and with plain encryption in cryptsetup (even with cryptsetup 2.0.0). This may change when users start adopting LUKS2 format and convert LUKS1 device with i.e.: cbc-essiv:sha256 mode to LUKS2. LUKS2 uses keyring service by default. Mike, If you accept the patch please resend also to stable kernels. [1] https://gitlab.com/cryptsetup/cryptsetup/blob/wip-luks2/tests/keyring-compat-test Ondrej Kozina (1): dm crypt: wipe kernel key copy after IV initialization drivers/md/dm-crypt.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) -- 1.8.3.1 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
