lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 5 Oct 2023 20:15:43 +0300
From:   Tatu Heikkilä <tatu.heikkila@...il.com>
To:     herbert@...dor.apana.org.au
Cc:     linux-kernel@...r.kernel.org, dm-devel@...hat.com,
        snitzer@...nel.org
Subject: (Bisected) Accessing opened Bitlocker partition leads to memory fault
 and kernel panic on Imac8,1

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ä

Powered by blists - more mailing lists