docs/v2.3.4-ReleaseNotes

   1 Cryptsetup 2.3.4 Release Notes
   2 ==============================
   3 Stable bug-fix release with a security fix (32-bit only).
   4
   5 All users of cryptsetup 2.2.x and later should upgrade to this version.
   6
   7 Changes since version 2.3.3
   8 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
   9
  10 * Fix a possible out-of-bounds memory write while validating LUKS2 data
  11   segments metadata (CVE-2020-14382).
  12
  13   This problem can be triggered only on 32-bit builds (64-bit systems
  14   are not affected).
  15
  16   LUKS2 format validation code contains a bug in segments validation code
  17   where the code does not check for possible overflow on memory allocation.
  18
  19   Due to the bug, the libcryptsetup can be tricked to expect such allocation
  20   was successful. Later it may read data from image crafted by an attacker and
  21   actually write such data beyond allocated memory.
  22
  23   The bug was introduced in cryptsetup 2.2.0. All later releases until 2.3.4
  24   are affected.
  25
  26   If you only backport the fix for this CVE, these master branch git commits
  27   should be backported:
  28     52f5cb8cedf22fb3e14c744814ec8af7614146c7
  29     46ee71edcd13e1dad50815ad65c28779aa6f7503
  30     752c9a52798f11d3b765b673ebaa3058eb25316e
  31
  32   Thanks to Tobias Stoeckmann for discovering this issue.
  33
  34 * Ignore reported optimal IO size if not aligned to minimal page size.
  35
  36   Some USB enclosures report bogus block device topology (see lsblk -t) that
  37   prevents LUKS2 format with 4k sector size (reported values are not correctly
  38   aligned). The code now ignores such values and uses the default alignment.
  39
  40 * Added support for new no_read/write_wrokqueue dm-crypt options (kernel 5.9).
  41
  42   These performance options, introduced in kernel 5.9, configure dm-crypt
  43   to bypass read or write workqueues and run encryption synchronously.
  44
  45   Use --perf-no_read_workqueue or --perf-no_write_workqueue cryptsetup arguments
  46   to use these dm-crypt flags.
  47
  48   These options are available only for low-level dm-crypt performance tuning,
  49   use only if you need a change to default dm-crypt behavior.
  50
  51   For LUKS2, these flags can be persistently stored in metadata with
  52   the --persistent option.
  53
  54 * Added support panic_on_corruption option for dm-verity devices (kernel 5.9).
  55
  56   Veritysetup now supports --panic-on-corruption argument that configures
  57   the dm-verity device to panics kernel if a corruption is detected.
  58
  59   This option is intended for specific configurations, do not use it in
  60   standard configurations.
  61
  62 * Support --master-key-file option for online LUKS2 reencryption
  63
  64   This can be used for reencryption of devices that uses protected key AES cipher
  65   on some mainframes crypto accelerators.
  66
  67 * Always return EEXIST error code if a device already exists.
  68
  69   Some libcryptsetup functions (activate_by*) now return EEXIST error code,
  70   so the caller can distinguish that call fails because some parallel process
  71   already activated the device.
  72   Previously all fails returned EINVAL (invalid value).
  73
  74 * Fix a problem in integritysetup if a hash algorithm has dash in the name.
  75
  76   If users want to use blake2b/blake2s, the kernel algorithm name includes
  77   a dash (like "blake2s-256").
  78   These algorithms can now be used for integritysetup devices.
  79
  80 * Fix crypto backend to properly handle ECB mode.
  81
  82   Even though it should never be used, it should still work for testing :)
  83   This fixes a bug introduced in cryptsetup version 2.3.2.
  84
  85 * TrueCrypt/VeraCrypt compatible mode now supports the activation of devices
  86   with a larger sector.
  87
  88   TrueCrypt/VeraCrypt always uses 512-byte sector for encryption, but for devices
  89   with a larger native sector, it stores this value in the header.
  90
  91   This patch allows activation of such devices, basically ignoring
  92   the mentioned sector size.
  93
  94 * LUKS2: Do not create excessively large headers.
  95
  96   When creating a LUKS2 header with a specified --offset larger than
  97   the LUKS2 header size, do not create a larger file than needed.
  98
  99 * Fix unspecified sector size for BitLocker compatible mode.
 100
 101   Some BitLocker devices can contain zeroed sector size in the header.
 102   In this case, the 512-byte sector should be used.
 103   The bug was introduced in version 2.3.3.
 104
 105 * Fix reading key data size in metadata for BitLocker compatible mode.
 106
 107   Such devices with an unexpected entry in metadata can now be activated.
 108
 109   Thanks to all users reporting these problems, BitLocker metadata documentation
 110   is not publicly available, and we depend only on these reports.
 111
 112 * Fix typos in documentation.