This bug was fixed in the package libblockdev - 2.20-7ubuntu0.1
---------------
libblockdev (2.20-7ubuntu0.1) disco; urgency=medium
[ intrigeri ]
* Use existing cryptsetup API for changing keyslot passphrase.
Cherry-pick upstream fix to use existing cryptsetup API for atomically
changing a keyslot passphrase, instead of deleting the old keyslot
before adding the new one. This avoids data loss when attempting to
change the passphrase of a LUKS2 device via udisks2, e.g. from GNOME
Disks.
Deleting a keyslot and then adding one is risky: if anything goes wrong
before the new keyslot is successfully added, no usable keyslot is left
and the device cannot be unlocked anymore. There's little chances this
causes actual problems with LUKS1, but LUKS2 defaults to the memory-hard
Argon2 key derivation algorithm, which is implemented in cryptsetup with
the assumption that it runs as root with no MEMLOCK ulimit; this
assumption is wrong when run by udisks2.service under
LimitMEMLOCK=65536, which breaks adding the new keyslot, and makes us
hit the problematic situation (user data loss) every time.
With this change, changing a LUKS2 passphrase via udisks2 will still
fail in some cases, until the MEMLOCK ulimit problem is solved in
cryptsetup or workaround'ed in udisks2. But at least, if it fails, it
will fail _atomically_ and the original passphrase will still work.
(Closes: #928893) (LP: #1837437)
-- Olivier Tilloy <[email protected]> Thu, 25 Jul 2019
12:33:46 +0200
** Changed in: libblockdev (Ubuntu Disco)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to libblockdev in Ubuntu.
https://bugs.launchpad.net/bugs/1837437
Title:
disk content permanently lost when changing LUKS password
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libblockdev/+bug/1837437/+subscriptions
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
