Bug #3311


TrueCrypt support may cause kernel crash

Added by about 2 years ago. Updated 5 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When working on tcplay:hammer2 device kernel can crash. Screenshots attached...


IMG_20220129_093359.jpg (3.19 MB) IMG_20220129_093359.jpg, 01/30/2022 02:33 AM
IMG_20220129_093321.jpg (3.67 MB) IMG_20220129_093321.jpg, 01/30/2022 02:33 AM
IMG_20220130_111602.jpg (3.4 MB) IMG_20220130_111602.jpg, 01/30/2022 02:33 AM
IMG_20220429_152146.jpg (2.49 MB) IMG_20220429_152146.jpg kernel crash, 04/29/2022 05:55 AM
Actions #1

Updated by tante.anna about 2 years ago

  • Priority changed from Normal to Low
  • % Done changed from 0 to 10

What happens if you don't use tcplay, but re-use/-initialize the same disk/slice with cryptsetup with default settings, and then fill up the new FS?

I seem to have a similar crash issue, both when using tcplay and cryptsetup. Due to a "fatal user access from kernel" issue with dm_crypt module. Which is maybe caused by something other than a software bug on my server.. [am testing scenarios at the moment]

Actions #2

Updated by almost 2 years ago

Well, after some updates tried testing again by encrypting swap on my drive (different drive). cryptsetup - stable, tcplay - dies quite fast even if swap is unused.

Actions #3

Updated by liweitianux almost 2 years ago

wrote in #note-2:

Well, after some updates tried testing again by encrypting swap on my drive (different drive). cryptsetup - stable, tcplay - dies quite fast even if swap is unused.

Hello, could you please describe the steps to reproduce this panic, e.g., tcplay to encrypt the swap.


Actions #4

Updated by almost 2 years ago

arcade@probe2\/home/arcade# swapoff /dev/da2s2
swapoff: removing /dev/da2s2 as swap device
arcade@probe2\/home/arcade# tcplay -c -d /dev/da2s2 -z -b SERPENT-256-XTS -x RIPEMD160-VC
Repeat passphrase:
Summary of actions:
 - Create volume on /dev/da2s2

 Are you sure you want to proceed? (y/n) y
Creating volume headers...
Depending on your system, this process may take a few minutes as it uses true random data which might take a while to refill
Writing volume headers to disk...
All done!
arcade@probe2\/home/arcade# tcplay -m swap0 -d /dev/da2s2
All ok!
arcade@probe2\/home/arcade# swapon /dev/mapper/swap0
swapon: adding /dev/mapper/swap0 as swap device

Sits idle when nothing happens, but if I startup browser, mail client, etc - quickly crashes with <attached image>.

Again, LUKS works pretty fine, plain cryptsetup also works, but binary can crash:

works: cryptsetup -c aes-xts-plain -s 256 -h ripemd160 -y create rootd /dev/da0s3
dumps core: cryptsetup -c aes-xts-plain -s 512 -h ripemd160 -y create rootd /dev/da0s3

Actions #5

Updated by liweitianux about 1 year ago

Hi, I followed your steps but I couldn't reproduce the panic...

I was testing in a VirtualBox VM. I added another disk to create the encrypted swap for the test.
My steps are as follows:

sudo kldload dm
sudo kldload dm_target_crypt
sudo gpt create da1
sudo gpt add -t swap da1
sudo tcplay -c -d /dev/da1s0 -z -b SERPENT-256-XTS -x RIPEMD160-VC
sudo tcplay -m test -d /dev/da1s0
sudo swapoff /dev/da0s1b
sudo swapon /dev/mapper/test
firefox &

I reduced the VM RAM to 512MB, so after starting FireFox the swap usage was ~700-900MB.
I browsed some pages and left the browser there for ~3 days. All worked well, no panic.

So I don't know yet what triggered the panic.

Nevertheless, the panic was cleared triggered by the AES code due to an invalid ioctl(/dev/crypto), which should be avoided.
I'll work on a fix to prevent ioctl() to simply panic the system.


Actions #6

Updated by liweitianux 5 months ago

  • % Done changed from 10 to 30

Although this issue hasn't been tracked down the root cause, I fixed aes_ctr_setkey() to validate the key length to avoid the panic. So it partially resolves this issue.

Committed to both the master and 6.4 release branches.


Also available in: Atom PDF