public inbox for cryptsetup@lists.linux.dev
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: cryptsetup development <cryptsetup@lists.linux.dev>
Subject: [ANNOUNCE] cryptsetup 2.7.4
Date: Tue, 30 Jul 2024 14:19:25 +0200	[thread overview]
Message-ID: <26c3ffac-5291-4e4e-9d5a-5ea8b33fbb5e@gmail.com> (raw)


[-- Attachment #1.1.1: Type: text/plain, Size: 3093 bytes --]

The cryptsetup 2.7.4 stable release is available at

                https://gitlab.com/cryptsetup/cryptsetup

Please note that release packages are located on kernel.org

                https://www.kernel.org/pub/linux/utils/cryptsetup/v2.7/

Feedback and bug reports are welcomed.

Cryptsetup 2.7.4 Release Notes
==============================
Stable bug-fix release.

All users of cryptsetup 2.7 should upgrade to this version.

Changes since version 2.7.3
~~~~~~~~~~~~~~~~~~~~~~~~~~~

* Detect device busy failure for device-mapper table-referenced devices.

   Some device-mapper ioctl failures can disappear in libdevmapper,
   causing the libcryptsetup wrapper to return an invalid error (EINVAL)
   instead of EEXIST or EBUSY. One such case is when there is a device
   creation race, and the device-mapper device name is created, but
   the following mapping table load fails. This can happen because some
   block devices used in table mapping have already been claimed by
   another process (the kernel needs exclusive access).

   The kernel ioctl properly returns EBUSY; this errno is lost in
   libdevmapper (dm_task_get_errno returns 0). It should be fixed by
   libdevmapper in the future.

   Such behavior was seen in the systemd way of handling dm-verity
   devices. With these changes, the code should react for EEXIST and
   EBUSY, as another process has already activated the device.

   Code calling libcryptsetup also must not check the underlying device
   with an exclusive open flag (O_EXCL). Otherwise, it could cause a race
   in the kernel device-mapper, resulting in no process succeeding device
   activation (see also CRYPT_ACTIVATE_SHARED flag below).

* Fix shared activation for dm-verity devices.

   The CRYPT_ACTIVATE_SHARED flag was silently ignored when activating
   dm-verity devices. Dm-verity shared activation is generally safe
   since all verity devices are read-only.

   The shared flag is a way to skip the exclusive access check for the
   device, allowing it to create multiple mappings with the same device or
   properly handle a racy concurrent activation of devices with the same
   name from different processes.

* Add --shared option for veritysetup open action.

   The option allows the data device to be used in multiple device-mapper
   table mappings (skip exclusive access check) or to allow concurrent
   dm-verity device activation of the same device (only one process
   succeeds in this case; the other will return EEXIST or EBUSY).

* Do not use exclusive flag for the allocated backing loop files.

   Using this flag is an undefined operation for opening an existing file.
   The flag should be used only for allocated loop (block) devices.

* Fixes for problems found by static analyzers and Valgrind.

   These include fixes for non-default libgcrypt, NSS, and Nettle
   cryptographic backends, buffer operations to avoid partial read/write,
   and several other workarounds for mostly false positive warnings.

* Fixes to tests and CI scripts.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4753 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

                 reply	other threads:[~2024-07-30 12:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26c3ffac-5291-4e4e-9d5a-5ea8b33fbb5e@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=cryptsetup@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox