[BUG] dm crypt: kernel keyring key processing bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux