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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 6 Oct 2023 08:04:18 +0700
From:   Bagas Sanjaya <>
To:     Tatu Heikkilä <>,
        Herbert Xu <>
Cc:     Linux Kernel Mailing List <>,
        Linux Device Mapper <>,
        Mike Snitzer <>,
        Alasdair Kergon <>,
        Linux Regressions <>
Subject: Re: (Bisected) Accessing opened Bitlocker partition leads to memory
 fault and kernel panic on Imac8,1

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:
> 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
> 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:

An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists