### Issue description

When creating nested dmcrypt mappings in /etc/crtypttab,
cryptdisks_start processes them from top to bottom.

The means that a some encrypted base device will be unlocked before any
nested encrypted devices based on it.

While this works fine for unlocking the encrypted disks, cryptdisk_stop
tries to remove the dmcrypt mappings in the same order which is clearly
wrong: It tries to remove the base mapping before any mappings bases on
it, which will fail because the base mapping is "busy" at that point.
Steps for reproducing the issue

Here is an example of a crypttab demonstating the issue:

# <target name>         <source device>
<key file>      <options> swap-myhost-pre4-dec     PARTUUID=88888888-02
                           unused_dummy
plain,noearly,cipher=aes-cbc-plain64,size=128,hash=sha256,keyscript=/etc/libexec/gen_hq_rand_psw
swap-myhost-pre3-dec     /dev/mapper/swap-myhost-pre4-dec
  unused_dummy
plain,noearly,cipher=blowfish-pcbc-essiv:sha256,size=128,hash=sha256,keyscript=/etc/libexec/gen_hq_rand_psw
swap-myhost-pre2-dec     /dev/mapper/swap-myhost-pre3-dec
  unused_dummy
plain,noearly,cipher=aes-ctr-plain64,size=128,hash=sha256,keyscript=/etc/libexec/gen_hq_rand_psw
swap-myhost-pre-dec      /dev/mapper/swap-myhost-pre2-dec
  unused_dummy
plain,noearly,cipher=aes-xts-benbi,size=256,hash=sha256,keyscript=/etc/libexec/gen_hq_rand_psw
swap-myhost-dec          /dev/mapper/swap-myhost-pre-dec
  unused_dummy
plain,swap,noearly,cipher=serpent-pcbc-essiv:sha256,size=256,hash=sha256,keyscript=/etc/libexec/gen_hq_rand_psw

The referenced key script (/etc/libexec/gen_hq_rand_psw) and another
helper script files used by it
(/etc/libexec/cached/keygen-octets-by-harvesting-entropy) have been
attached to this report.

### Expected behaviour

The cryptdisks_stop script should process the crypttab entries in the
reverse order of how cryptdisks_start processes them.

### External links

The original bug report, delivered to upstream first by mistake:

https://gitlab.com/cryptsetup/cryptsetup/-/issues/719#note_863814204

Control: tag -1 moreinfo

I believe cryptdisks_start(8) and cryptdisks_stop(8) processes mappings
in the order given on the command line, which is intentional.  Are you
talking about SysV init scripts?

Am Sat, 5 Mar 2022 13:32:24 +0100
schrieb Guilhem Moulin <guilhem@debian.org>:

Yes, you are right. The problem actually refers
to "/etc/init.d/cryptdisks".

Or to be more precise, to the do_stop() function called from
there.

That function is defined in line 180 of
/lib/cryptsetup/cryptdisks-functions and the problem is in line 188
which calls

crypttab_foreach_entry _do_stop_callback

which is exactly the same as do_start() does. And hence the entries are
processed in the same order instead of the reverse order, which then
leads to the problem.

The problem kicks in when I want to shut down the Linux box with the
encrypted swap which has been set up by the "start" action of the
service script.

When called again with the "stop" action as part of the shutdown
sequence, the problem happens and the script hangs for a long while
because of the "busy"-problem until giving up and shutting down anyway.

Control: retitle -1 `/etc/init.d/cryptdisks stop` should safely traverse nested block device stacks
Control: tag -1 - moreinfo

For do_start() we're reading crypttab(5) sequentially as we don't have
enough information about nesting, however for do_stop() we have that
information in the mapping table, so no need to reverse crypttab(5)
entries or guess nesting.  I need to do some tests but I guess running
foreach_cryptdev() in the callback should be enough.

Control: tag -1 pending

Fixed at https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/a5cdd34a43458e4d2a7ff0d9b7b402374382a75a
I think.  Please confirm :-)  You'll need to apply
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/048f504df31277d8d47b01ffa4c864b8b282e6df
beforehand and probably remove the changes to debian/tests/* from the
patch.

We believe that the bug you reported is fixed in the latest version of
cryptsetup, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1006802@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guilhem Moulin <guilhem@debian.org> (supplier of updated cryptsetup package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 15 Jul 2022 01:49:59 +0200
Source: cryptsetup
Architecture: source
Version: 2:2.5.0~rc1-1
Distribution: experimental
Urgency: low
Maintainer: Debian Cryptsetup Team <pkg-cryptsetup-devel@alioth-lists.debian.net>
Changed-By: Guilhem Moulin <guilhem@debian.org>
Closes: 1006802
Changes:
 cryptsetup (2:2.5.0~rc1-1) experimental; urgency=low
 .
   * New upstream release candidate 2.5.0.  Highlights include:
     + Remove cryptsetup-reencrypt(8) executable, use `cryptsetup reencrypt`
       instead (for both LUKS1 and LUKS2).
     + Split manual pages into per-action pages, for instance cryptsetup-open.8
       which can be consulted with `man cryptsetup open`.
     + Add LUKS2 encryption removal support with `cryptsetup reencrypt
       --decrypt`.
     + Preserve unknown metadata option (features implemented in more recent
       cryptsetup releases) during reencryption.
   * Salsa CI's deploy stage: Use a Bullseye image.
   * Salsa CI's deploy stage: Use apt-get(8) not apt(8).
   * Salsa CI's deploy stage: Replace `cp` with `install`.
   * Salsa CI's reprotest job: Remove '--no-diffoscope' flag.
   * Salsa CI's reprotest job: Update reason for running under 'nocheck' build
     profile.
   * d/README.source: Update text to reflect current practices.
   * DEP-8: Run installed binaries and libraries through the full upstream test
     suite (needs machine-level isolation).
   * Retroactivately add NEWS.Debian for #949336.
   * d/t/control: Add 'Depends: xxd' for 'Tests: cryptdisks' stanza.
   * foreach_cryptdev(): Process each device *after* its slaves.
   * do_stop(): Remove device holders beforehand. (Closes: #1006802)
   * Fix space damage.
   * d/u/metadata: Add FAQ URL.
   * Refresh lintian overrides to accommodate lintian v2.115.
   * d/control: New Build-Depends: asciidoctor (unless under 'nodoc' build
     profile).
   * d/cryptsetup.docs: Fix FAQ filename.
   * Move usr/share/man/*/* glob to debian/*.manpages where it belongs.
   * Update d/libcryptsetup12.symbols.
   * Bump Standards-Version to 4.6.1 (no changes needed).
   * Update d/copyright.
Checksums-Sha1:
 afd3ce8ca2a3aba4f227a52e94061f11b5223fb4 3242 cryptsetup_2.5.0~rc1-1.dsc
 b4b1db0925b39a16d261a29294c348791625299b 11490227 cryptsetup_2.5.0~rc1.orig.tar.gz
 4e29ca5cf050638e7474e5eedc3f9cfa0f8993bb 129412 cryptsetup_2.5.0~rc1-1.debian.tar.xz
 b7de8c4f0d7a87b440843d4ce982f4aa43418ae4 11121 cryptsetup_2.5.0~rc1-1_amd64.buildinfo
Checksums-Sha256:
 906137a5add043567f17bb4cf77053b2167a406557afd78ca59210c1c89c054c 3242 cryptsetup_2.5.0~rc1-1.dsc
 31659cc00f64ac3c9028ffaecebdb3725bc9897d31b6e39968d1791ecbd19825 11490227 cryptsetup_2.5.0~rc1.orig.tar.gz
 c57053b72b95d0c6c13687d1711583001fb51f563d7b6be54ed0d2f74a775076 129412 cryptsetup_2.5.0~rc1-1.debian.tar.xz
 b2c13483784da4ec9acd714e05c8dc2f9a8ef85b9ec43db5a36e813278b6918a 11121 cryptsetup_2.5.0~rc1-1_amd64.buildinfo
Files:
 6630be3eafd409863aeeecab0af6c59c 3242 admin optional cryptsetup_2.5.0~rc1-1.dsc
 c2bfaceac7ea1954fff001e6adf67475 11490227 admin optional cryptsetup_2.5.0~rc1.orig.tar.gz
 77721c1e8674274cd5d05d491806b41e 129412 admin optional cryptsetup_2.5.0~rc1-1.debian.tar.xz
 b3e5edaae81e2bad01a295563877fe53 11121 admin optional cryptsetup_2.5.0~rc1-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmLQrSYACgkQ05pJnDwh
pVJ62RAAmYGZJ8pn0diaTIiOdVyfi/a8zDpsY4hB8y8yupWi+Or65veS0OP9cIXZ
QM1cmAtr4H9nCxs0oHX1vA1ZzG+9kesohnSQ5AzEvWN6UKo4WwTYsmyqpbYAykLM
ct0gvnipvJaVH40zLWqncvUaM67A1pVRs25Ctvpu5AHzzKTp/zN0k8c38nDbpPFw
93JodKfRVvRgN36iU/Ihx72z24G293FSJEQ1Ps1+tlE3MGzFgxLknA0Euec+ysPo
hmt2ztJcGD9pM1FIREByGX8YRX53Ek9pSuMAbA4ex9oRKCDzFe+OXOO8MAIdD8lz
eW4/Bck82hlcC5cp5QpeiS2OLT+tckuMsdfCcoI3R0BOMJ7tj3mGauDw4wvUc39f
Se36c7Xxl86m6gs+1VUgeL3rcoWl6O7zsGT+fDmOFceOHU9zPm08rRVEWWBfCubK
Ev+K0QSmgc6KjUk8IR4EnrqZNdopdhoQ5VyNefwkYfpAmtA8gczdKqyZ4cCHkQvb
SRt+dLKwr57CzjT2R4dP4/JKTm/p0eajSTZfjdQ8eBumnh1yScWPaFQYTLdlhcRU
ElMVQEje8Jw9+4WI/whdaalq5C+xyAmvtb3XEXfl1YP7cZqB10RdpEGibFySn4hp
XQZa3M6J6rNZzMeb29XfvYthV7DA5UKvvVDC/De7DaR9Qwqh6EI=
=9K6V
-----END PGP SIGNATURE-----