On Thu, Oct 05, 2023 at 08:15:43PM +0300, Tatu Heikkilä wrote: > 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. > Thanks for the regression report. I'm adding it to regzbot: #regzbot ^introduced: e3023094dffb41 #regzbot title: kernel panic when accessing opened bitlocker partition due to avoiding MAX_CIPHER_BLOCKSIZE #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=217982 -- An old man doll... just what I always wanted! - Clara
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
