[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZR9dEiXhQv-wBVA2@debian.me>
Date: Fri, 6 Oct 2023 08:04:18 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Tatu Heikkilä <tatu.heikkila@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Device Mapper <dm-devel@...hat.com>,
Mike Snitzer <snitzer@...nel.org>,
Alasdair Kergon <agk@...hat.com>,
Linux Regressions <regressions@...ts.linux.dev>
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:
> 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
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists