Bug #3311
open
TrueCrypt support may cause kernel crash
30%
Description
When working on tcplay:hammer2 device kernel can crash. Screenshots attached...
Files
Updated by tante.anna almost 3 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]
Updated by arcade@b1t.name over 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.
Updated by liweitianux over 2 years ago
arcade@b1t.name 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.
Thanks.
Updated by arcade@b1t.name over 2 years ago
- File IMG_20220429_152146.jpg IMG_20220429_152146.jpg added
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 Passphrase: 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 Passphrase: 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
Updated by liweitianux almost 2 years 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.
Cheers,
Aaron
Updated by liweitianux about 1 year 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.
Updated by 
