Hi, live-boot fails to make use of the dm-verity related mount options when the `.verity` file of the relevant filesystem is removed. As far as I know, Debian itself does not make use of these options and they don't seem widely popular, but we're aware of the options being used. For those relying on e.g. dm-verity-enforce-roothash-signature, this introduces a security hole as the authenticity and integrity check enforcement can be bypassed. Filing this bug publicly has been discussed with the Debian Security Team. There is no CVE identifier yet. X41 tracks the issue as X41-2026-004. All versions released since the introduction in 1:20220505 seem to be affected. Consider an exemplary Secure Boot environment with the following file structure: /live/vmlinuz /live/initrd /live/filesystem.squashfs /live/filesystem.squashfs.verity /live/filesystem.squashfs.roothash /live/filesystem.squashfs.roothash.p7s - The bootloader is signed with UEFI Secure Boot keys - UEFI verifies and loads the bootloader - The bootloader verifies the kernel and initramfs - Bootloader loads the kernel with the preconfigured kernel command-line - Initramfs does its thing, such as mounting the rootfs - The filesystem itself is unprotected This is where dm-verity comes in to prevent tampering of the filesystem's underlying block device. Supported options of live-boot are (see the documentation at [0]): - dm-verity-oncorruption=ignore|panic|restart Results in the chosen option when a corrupted dm-verity device is encountered. - dm-verity-root-hash=IMAGE:ROOTHASH,IMAGE2:ROOTHASH2 ... IMAGEn:ROOTHASHn Allows pinning the root hash on the kernel command-line - dm-verity-enforce-roothash-signature Enforces that the root hash has to be checked against a signature (`.roothash.p7s`). The signature is checked against the keyring (AFAIK it can be compiled-in, or Secure Boot keys taken from UEFI). All of the above options can be defeated by deleting the `.verity` file from the live medium. The kernel command-line parameters for live-boot are parsed in [1] and then used below the lines [2] if the `.verity` file exists. An attacker could manipulate the filesystem, and delete the `.verity` file. The system would then boot with the manipulated filesystem, disregarding all protection that dm-verity promises. It should be noted that the dm_verity.require_signatures=1 (see `modinfo dm_verity`) option does not prevent this either, as the dm_verity module is not used without the `.verity` file present. Also note that validating the existence and/or integrity of the `.verity`, `.roothash`, or `.roothash.p7s` files in the bootloader (see e.g. [3]) does not offer sufficient protection if the attacker controls the block device, as the attacker could delete the files between the bootloader and live-boot checking them. Possible workarounds may include using dm-mod.create (see [4]), or manually patching the initramfs. No LLMs were used in finding this bug or writing this text. [0]: https://manpages.debian.org/bookworm/live-boot-doc/live-boot.7.en.html#dm [1]: https://salsa.debian.org/live-team/live-boot/-/blob/a8ddd8e0b204ee79c3d9eb17252a332403558579/components/9990-cmdline-old#L40-51 [2]: https://salsa.debian.org/live-team/live-boot/-/blob/a8ddd8e0b204ee79c3d9eb17252a332403558579/components/9990-overlay.sh#L112-114 [3]: https://www.gnu.org/software/grub/manual/grub/html_node/verify_005fdetached.html [4]: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-init.html