[pkg-cryptsetup-devel] Bug#1113897: Bug Report: cryptsetup - LUKS2 integrity protection fails on Debian 13 (Trixie)

[Sebastian Kern]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20250903/914400cb/attachment.htm>