### Issue description I have the impression that (unless `--disable-keyring` is supplied when opening a volume), the volume key is stored in two different data structures in RAM: 1. The dm_crypt structures. These are correctly wiped by `cryptsetup luksSuspend`. 2. The kernel keyring. This is (apparently) _not_ wiped. I believe this should be documented; perhaps even fixed, if reasonably possible (it's a bit unclear to me whether this is in the scope of this project, or rather an issue of systemd etc.). But it might also be that I have misunderstood something. In that case I would be sorry for spamming this issue ticker. Thank you very much for maintaining such a critical piece of infrastructure, I very much appreciate it! ### Steps for reproducing the issue ``` dd if=/dev/zero of=foo.img bs=1 seek=50M count=0 DEVICE=$(losetup -f --show foo.img) echo -n abc | cryptsetup luksFormat --batch-mode --uuid 12345678-1234-1234-1234-123456789abc "$DEVICE" echo -n abc | cryptsetup luksOpen "$DEVICE" foo cryptsetup luksSuspend --debug foo grep 12345678-1234-1234-1234-123456789abc /proc/keys ``` ### Additional info This is cryptsetup 2.8.6 on NixOS. ### Debug log ``` # Requesting kernel key cryptsetup:12345678-1234-1234-1234-123456789abc-d0 (type logon). # keyring_request_key_id failed with errno 126. # Releasing crypt device /dev/loop0 context. # Releasing device-mapper backend. ```