Public bug reported:

After updating to linux-image-7.0.0-28-generic, cryptsetup can no longer
open my existing LUKS2 volume on an NVMe drive. 7.0.0-29 has the same
problem. Booting back into 7.0.0-22-generic makes it work again — same
disk, same LUKS metadata, same key file, same cryptsetup
(2:2.8.4-1ubuntu4) in all three cases.

On the bad kernels:

  $ sudo cryptsetup open --test-passphrase --key-slot 1 \
        --key-file <keyfile> /dev/nvme1n1p1
  IO error while decrypting keyslot.
  Keyslot open failed.

With --debug the error comes right after "Reading keyslot area
[0x47000]", failing with -5 (EIO). Both keyslots fail the same way,
every time. dmesg shows a read error at that moment:

  I/O error, dev nvme1n1, sector 858, op 0x0:(READ) flags 0x800
  phys_seg 31 prio class 2

(for keyslot 0 it's sector 354 instead)

I don't think the disk is at fault:

- Reading both complete keyslot areas with dd iflag=direct works,
  including the exact sectors dmesg complains about.
- luksDump and luksHeaderBackup work fine.
- SMART is clean.
- The two failing sectors sit at the same relative offset (+256
  sectors) inside their respective keyslot areas, which looks like an
  I/O path problem, not two coincidental bad blocks.

This looks like the same regression as Fedora reported in Red Hat bug
2489082 (https://bugzilla.redhat.com/show_bug.cgi?id=2489082): same
error message, broken in 7.0.11/7.0.12, working in 7.0.10, fixed in
7.0.13. That matches Ubuntu exactly: 7.0.0-28.28 is the first upload
that merged stable v7.0.9 through v7.0.12, and 7.0.0-29.29 adds no
stable release beyond that, so the 7.0.13 fix is missing from both (I
checked drivers/iommu/dma-iommu.c in the resolute kernel git at both
tags).

My suspicion: v7.0.11 backported "iommupt: Avoid rewalking during map"
(92ec4e9185f3, upstream d6c65b0fd6218), after which a zero-length
iommu_map() fails instead of being a no-op. That breaks
iommu_dma_iova_link_swiotlb() for bounced DMA segments with an
unaligned tail, which is what cryptsetup's O_DIRECT keyslot read
produces (256000 bytes — a multiple of 512 but not of 4096). The likely
fix is upstream 6ec91df8aff77e2e8fe3179c1f3fc15b43a40ba3 ("iommu/dma:
Do not try to iommu_map a 0 length region in swiotlb"), which went into
stable v7.0.13 as b16f8d40bac9. The v7.0.13 stable merge containing it
(LP: #2158003) is already on the resolute master-next branch, but it
missed the 7.0.0-28.28 cut, and 7.0.0-29.29 also shipped without it.
Could that merge be released, or the single commit cherry-picked?

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163151

Title:
  cryptsetup can no longer open LUKS2 keyslots on 7.0.0-28/-29: "IO
  error while decrypting keyslot" (works on 7.0.0-22)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163151/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to