RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

LUKS2 specification [1] defines limited set of valid LUKS2 metadata sizes (see chapter 2.1 and 2.2 of the specification). Currently cryptsetup creates only 16 KiB variant of LUKS2 metadata (4KiB binary header + 12KiB json area). This applies also to LUKS2 containers created via up-conversion from LUKS1 format.

Unfortunately current cryptsetup (any upstream version < cryptsetup-2.0.6) rejects any non-default LUKS2 metadata size (32KiB and larger) as invalid LUKS2 format. This is bug in internal validation code but format (metadata itself) is not affected in any way.

Even though current cryptsetup in RHEL8 does not support creating LUKS2 containers with non-default metadata size, it must be able to parse, validate, load and modify any LUKS2 metadata size specified in LUKS2 format documentation [1].

[1] https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf

Fixed upstream by:

https://gitlab.com/cryptsetup/cryptsetup/commit/7713df9e411fc2572cded9053886bbfe9712c784

Created attachment 1509759 [details]
Archive containing all LUKS2 metadata variants

All images have single active keyslot 0 that can be unlocked with passphrase: Qx3qn46vq0v

To verify this bug, fixed cryptsetup must unlock all metadata variants (and also be able to perform any metadata modifying operation). Current cryptsetup-2.0.4-2.el8 can unlock/handle only test_image_16 (16KiB LUKS2 metadata).

Hi Ondrej,

there is no reproducer to verify this bug. Are you able to verify it yourself or provide a reproducer?

I don't have better reproducer than one desribed in comment #3 (test images) and comment #4. To test unlock capability just run cryptsetup open command, to test write capability you may try to add new keyslot (cryptsetup luksAddKey). To test it on real drive just dd the test image in head of your test block device.

Thanks Ondrej,

I was able to reproduce this issue on RHEL-8.0-20181120.0 and verify the fix on RHEL-8.0.0-20190129.1. Moving to verified.