Control: retitle -1 live-boot: CVE-2026-89169: dm-verity related parameters ineffective when .verity file is removed
Hi, On Tue, Sep 01, 2026 at 08:39:33PM +0200, [email protected] wrote: > Package: live-boot > Version: 1:20230131+deb12u1 > Severity: critical > Tags: security > Justification: root security hole > X-Debbugs-Cc: [email protected], Debian Security Team > <[email protected]> > > 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. CVE-2026-89169 got assigned for this issue. Regards, Salvatore
