Created attachment 305190 [details] panic dmesg Here are dmesg logs and .config for my email bug report.
Created attachment 305191 [details] panic dmesg #2
Created attachment 305192 [details] panic dmesg #3
Created attachment 305193 [details] panic dmesg #4
Created attachment 305194 [details] kernel configuration
Created attachment 305195 [details] Only the crash part from older dmesg logs
Is this a regression, i.e. did it ever work before? If it did, could you please bisect? https://docs.kernel.org/admin-guide/bug-bisect.html
Ah okay, I was going by https://docs.kernel.org/admin-guide/reporting-issues.html#things-each-report-should-mention where it says reports by email can have their attachments laid here. I just sent the following email off to the mailing lists, and I assume the discussion will happen there: "Hello, I think you and the lists are right recipients, forgive me if not, I've never reported kernel bugs before. Naively this seems a crypto issue and Herbert Xu from crypto maintainers made the buggy commit, but it edits drivers/md/dm_crypt.c maintained by dm-devel people per MAINTAINERS, so I'm going by that. At the center of the issue is my Imac8,1 and an external 2TB SSD with 5 partitions: an EFI+MBR portable Arch Linux install with LUKS encrypted ext4 /home, and a 1.7TB exFAT encrypted with Bitlocker. Mounting the LUKS partition works fine on all my 4 computers (Imac8,1, Imac12,2, two generic Intels; Fedora's GNOME gvfs volume monitor often crashes on mount using this drive), and mounting the Bitlocker partition works on all other computers, but my Imac8,1. On my other computers, I can boot into the portable install which automounts the Bitlocker partition fine. However, on my Imac8,1, regardless if I boot into the external drive's portable Arch Linux install, or use the Imac's own internal Debian testing install, any post-6.4 kernel reliably panics (50+ times so far, 100% of the time) when accessing the unlocked Bitlocker volume: # cryptsetup open /dev/sdb5 --type bitlk crucial Enter passphrase for /dev/sdb5: # mount /dev/mapper/crucial temp [kernel immediately panics if I try to tab-complete the mount point, making the shell also access the decrypted device I assume, or try to run the command] I originally ran into this when mounting using XFCE's Thunar implementation. Using it, the mount fails with "Operation was cancelled" and the system crashes within a minute. Git bisect lead me to: # first bad commit: [e3023094dffb41540330fb0c74cd3a019cd525c2] dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE If I git revert e3023094dffb41540330fb0c74cd3a019cd525c2 on current Linus' git master, the issue goes away. So I'm personally not all that affected anymore (if I'm ready to compile my kernels from now on), and I understand that you have no clear way to reproduce this as it seems strongly bound to hardware, but seems like this could point to a potentially serious security issue since it involves both crypto and undefined behaviour. Kdump dmesg logs (the error output is not completely consistent between panics) & .config can be found in a dummy Bugzilla report https://bugzilla.kernel.org/show_bug.cgi?id=217982 Please let me know if I can help you in any way. I don't mind using this as a gateway to learn more about kernel debugging etc. Best regards, Tatu Heikkilä"
There's a working patch now at https://lore.kernel.org/all/ZR9l446ndB4n1Xl4@gondor.apana.org.au/ on its way for release, so I'm marking this as resolved.