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
    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 <>  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
Bugs, which is subscribed to Ubuntu.

  disk content permanently lost when changing LUKS password

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to