<div dir="ltr">Package: cryptsetup<br>Version: 2.7.5-1<br>Severity: critical<br><br>Dear Maintainers,<br><br>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.<br><br>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.<br><br>--- SYSTEM INFORMATION ---<br><br>Kernel: Linux debian 6.12.38+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16) x86_64 GNU/Linux<br><br>Distribution: No LSB modules are available.<br>Distributor ID:   Debian<br>Description:    Debian GNU/Linux 13 (trixie)<br>Release:  13<br>Codename:   trixie<br><br>Cryptsetup Version: cryptsetup 2.7.5 flags: UDEV BLKID KEYRING KERNEL_CAPI HW_OPAL<br>Debian Version: 13.0<br>Live-System ISO: debian-live-13.0.0-amd64-xfce.iso<br><br>--- STEPS TO REPRODUCE ---<br><br>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.<br><br>#!/bin/bash<br>sudo cryptsetup close 123laufwerk<br>rm -f 123container.img<br>fallocate -l 100M 123container.img<br>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<br>sudo cryptsetup open --iv-large-sectors --allow-discards 123container.img 123laufwerk<br>sudo mkfs.ext4 -b 4096 /dev/mapper/123laufwerk<br>sudo mkdir -p /mnt<br>sudo mount /dev/mapper/123laufwerk /mnt<br>sudo dd if=/dev/urandom of=/mnt/beweis.txt bs=4096 count=1<br>BLOCKNUMMER=$(sudo debugfs -R "stat /beweis.txt" /dev/mapper/123laufwerk | grep "Blocks:" | sed 's/.*(\(.*\))//')<br>OFFSET_SEKTOREN=$(sudo cryptsetup luksDump 123container.img | grep "Payload offset" | awk '{print $3}')<br>PHYSIKALISCHER_OFFSET=$((OFFSET_SEKTOREN * 512 + BLOCKNUMMER * 4096))<br>HASH_VORHER=$(sha512sum 123container.img)<br>sudo dd if=/dev/urandom of=123container.img bs=1 count=4096 seek=$PHYSIKALISCHER_OFFSET conv=notrunc<br>HASH_NACHHER=$(sha512sum 123container.img)<br>sync; echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null<br><br># For verification<br>echo "Hash before: $HASH_VORHER"<br>echo "Hash after:  $HASH_NACHHER"<br><br># The actual test<br>cat /mnt/beweis.txt<br>sudo dmesg | grep "INTEGRITY CHECKSUM FAILED"<br><br># Cleanup<br>sudo umount /mnt<br>sudo cryptsetup close 123laufwerk<br>rm 123container.img<br><br>--- OBSERVED BEHAVIOR ---<br><br>1.  The `sha512sum` values for the container file before and after the `dd` manipulation are different, proving the corruption was successful.<br>2.  The command `cat /mnt/beweis.txt` outputs random garbage data to the terminal without any error.<br>3.  The `dmesg` command shows no "INTEGRITY CHECKSUM FAILED" message.<br><br>--- EXPECTED BEHAVIOR ---<br><br>1.  The `sha512sum` values should be different.<br>2.  The command `cat /mnt/beweis.txt` should fail with an "Input/output error".<br>3.  The `dmesg` command should show a message similar to "device-mapper: crypt: ... INTEGRITY CHECKSUM FAILED".<br><br>The silent failure to detect data corruption is a critical security issue. Thank you for your time and your work on Debian.</div>