Your message dated Thu, 4 Sep 2025 13:16:30 +0200 with message-id <[email protected]> and subject line Re: Bug#1113897: Bug Report: cryptsetup - LUKS2 integrity protection fails on Debian 13 (Trixie) has caused the Debian Bug report #1113897, regarding Bug Report: cryptsetup - LUKS2 integrity protection fails on Debian 13 (Trixie) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1113897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113897 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: cryptsetup Version: 2.7.5-1 Severity: critical Dear Maintainers, I am reporting a critical issue where the LUKS2 integrity protection feature in cryptsetup fails to detect and prevent access to corrupted data. The test was performed on a current Debian 13 (Trixie) live system. A minimal, reproducible test case demonstrates that after physically corrupting the data block of a file within an integrity-protected LUKS2 container, the file can still be read, yielding garbage data instead of the expected I/O error. --- SYSTEM INFORMATION --- Kernel: Linux debian 6.12.38+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16) x86_64 GNU/Linux Distribution: No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 13 (trixie) Release: 13 Codename: trixie Cryptsetup Version: cryptsetup 2.7.5 flags: UDEV BLKID KEYRING KERNEL_CAPI HW_OPAL Debian Version: 13.0 Live-System ISO: debian-live-13.0.0-amd64-xfce.iso --- STEPS TO REPRODUCE --- The following shell script reliably reproduces the issue. It creates an integrity-protected container, isolates a single data block, physically corrupts it (verified via sha512sum), and then attempts to read it. #!/bin/bash sudo cryptsetup close 123laufwerk rm -f 123container.img fallocate -l 100M 123container.img sudo cryptsetup luksFormat --cipher aes-xts-plain64 --type luks2 --key-size 512 --hash sha512 --pbkdf argon2id --pbkdf-memory 4194304 --pbkdf-parallel 8 --iter-time 45000 --use-random --disable-keyring --sector-size 4096 --integrity hmac-sha512 123container.img sudo cryptsetup open --iv-large-sectors --allow-discards 123container.img 123laufwerk sudo mkfs.ext4 -b 4096 /dev/mapper/123laufwerk sudo mkdir -p /mnt sudo mount /dev/mapper/123laufwerk /mnt sudo dd if=/dev/urandom of=/mnt/beweis.txt bs=4096 count=1 BLOCKNUMMER=$(sudo debugfs -R "stat /beweis.txt" /dev/mapper/123laufwerk | grep "Blocks:" | sed 's/.*(\(.*\))//') OFFSET_SEKTOREN=$(sudo cryptsetup luksDump 123container.img | grep "Payload offset" | awk '{print $3}') PHYSIKALISCHER_OFFSET=$((OFFSET_SEKTOREN * 512 + BLOCKNUMMER * 4096)) HASH_VORHER=$(sha512sum 123container.img) sudo dd if=/dev/urandom of=123container.img bs=1 count=4096 seek=$PHYSIKALISCHER_OFFSET conv=notrunc HASH_NACHHER=$(sha512sum 123container.img) sync; echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null # For verification echo "Hash before: $HASH_VORHER" echo "Hash after: $HASH_NACHHER" # The actual test cat /mnt/beweis.txt sudo dmesg | grep "INTEGRITY CHECKSUM FAILED" # Cleanup sudo umount /mnt sudo cryptsetup close 123laufwerk rm 123container.img --- OBSERVED BEHAVIOR --- 1. The `sha512sum` values for the container file before and after the `dd` manipulation are different, proving the corruption was successful. 2. The command `cat /mnt/beweis.txt` outputs random garbage data to the terminal without any error. 3. The `dmesg` command shows no "INTEGRITY CHECKSUM FAILED" message. --- EXPECTED BEHAVIOR --- 1. The `sha512sum` values should be different. 2. The command `cat /mnt/beweis.txt` should fail with an "Input/output error". 3. The `dmesg` command should show a message similar to "device-mapper: crypt: ... INTEGRITY CHECKSUM FAILED". The silent failure to detect data corruption is a critical security issue. Thank you for your time and your work on Debian.
--- End Message ---
--- Begin Message ---On Wed, 03 Sep 2025 at 20:04:30 +0000, Sebastian Kern wrote: > sudo cryptsetup open --iv-large-sectors --allow-discards 123container.img > 123laufwerk This fails with the following error on my Trixie VM. cryptsetup: Large IV sectors option is supported only for opening plain type device with sector size larger than 512 bytes. (And after removing --iv-large-sectors, cryptsetup still refuses to open the device and fails with "Discard/TRIM is not supported". Removing both flags and moving on.) > BLOCKNUMMER=$(sudo debugfs -R "stat /beweis.txt" /dev/mapper/123laufwerk | > grep "Blocks:" | sed 's/.*(\(.*\))//') That yields an empty value here. I guess you meant `debugfs -R "blocks /beweis.txt" /dev/mapper/123laufwerk` instead. > OFFSET_SEKTOREN=$(sudo cryptsetup luksDump 123container.img | grep "Payload > offset" | awk '{print $3}') That yields an empty value here, see Milan's reply. Use `dmsetup table 123laufwerk_dif | cut -d' ' -f5` instead. > PHYSIKALISCHER_OFFSET=$((OFFSET_SEKTOREN * 512 + BLOCKNUMMER * 4096)) That doesn't account for integrity metadata. > 1. The `sha512sum` values for the container file before and after the `dd` > manipulation are different, proving the corruption was successful. But it doesn't prove that underlying storage area for /beweis.txt was corrupted. > 2. The command `cat /mnt/beweis.txt` outputs random garbage data to the > terminal without any error. But that's the same random garbage as before the corruption attempt, which indicates a logic error in the corruption logic rather than an error in the integrity layer. To simplify sector arithmetic, you can skip the FS and fill the mapped device with random data instead. Then corrupt say 16k somewhere in the middle, and try to read the mapped device content. That should trigger an INTEGRITY AEAD ERROR. Also FWIW authenticated disk encryption is encryption according to upstream documentation. -- Guilhem.
signature.asc
Description: PGP signature
--- End Message ---
