1. Please describe the problem:

Since kernel-7.0.11-200.fc44, opening any LUKS-encrypted volume other than the already-unlocked root device fails during keyslot decryption. cryptsetup reports:

    IO error while decrypting keyslot.
    Keyslot open failed.

GNOME Disks reports the same failure as: input/output error (udisks-error-quark, 0)

The failure occurs both via the GNOME/udisks unlock workflow AND when running `cryptsetup open` directly as root in a terminal, so it is not a udisks, polkit, or SELinux issue (confirmed: `setenforce 0` makes no difference).

Facts that narrow it down:
- Reproduces with USB-Flashdrive, USB SATA(HDD), and NVMe encrypted drives (USB and Thunderbolt)
- The encrypted root volume still unlocks normally at boot (initramfs), so dm-crypt mapping with an already-derived key works. The failure is specifically in keyslot-area decryption when opening a volume from the running system.
- Unencrypted external drives mount without issue.
- `cryptsetup benchmark` shows aes-xts-plain64 working normally, so in-memory crypto is fine.
- The same drives open without error on CachyOS and Ubuntu running the same upstream kernel version 7.0.xx, and on Fedora before 7.0.11.
- cryptsetup / cryptsetup-libs are unchanged (F44 baseline; not downgradable), ruling out a userspace cryptsetup change.

This points to a regression in the crypto / dm-crypt / direct-I/O read path introduced between 7.0.10 and 7.0.11.


2. What is the Version-Release number of the kernel:

kernel-7.0.11-200.fc44.x86_64 (first bad build). Also reproduces on kernel-7.0.12-200.fc44.x86_64.


3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?

Yes, it worked previously. The issue first appears in kernel-7.0.11-200.fc44.x86_64.
kernel-7.0.10-200.fc44.x86_64 works correctly; kernel-7.0.11-200.fc44.x86_64 fails. This was confirmed by a clean bisection across two separate F44 systems: on one, upgrading from 7.0.8 to 7.0.12 introduced the failure and reverting to 7.0.8 fixed it; testing intermediate builds from Koji isolated the first bad build to 7.0.11. Booting back into 7.0.10 reliably restores correct behavior.


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes, reproducible 100% of the time.
1. Boot kernel-7.0.11-200.fc44 or newer.
2. Attach any LUKS-encrypted external drive (USB/Thunderbolt).
3. Run: sudo cryptsetup open /dev/sdX or /dev/nvmeXnXpX test   (enter the correct passphrase)

Actual result: "IO error while decrypting keyslot. Keyslot open failed." — the volume does not open.

Expected result: the volume opens, as it does on kernel-7.0.10-200.fc44 and on other distributions.


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

[Not yet tested.]


6. Are you running any modules that not shipped with directly Fedora's kernel?:

No. Stock Fedora kernel only; no third-party or out-of-tree modules.


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Can attach upon request, but I am actually glad to be on a working kernel version rn.

Reproducible: Always