Debian live-boot dm-verity signature enforcement bypass when.verity is missing

live-boot ff8867c allows attackers to bypass the dm-verity-enforce-roothash-signature protection mechanism when the.verity file is missing.

• Debian live-boot is marked affected at the git revision beginning with ff8867c, with versionType set to git.
• The product has default_status set to unknown; the record does not identify all affected packaged releases, parallel branches, or deployment configurations.
• No fixed release, corrected version boundary, or solution is supplied. The status of releases other than the identified revision remains unknown.

Debian live-boot contains an improper cryptographic signature verification weakness classified as CWE-347. The dm-verity-enforce-roothash-signature mechanism is intended to protect verification of the root hash signature, but that protection can be bypassed when the .verity file is missing. The record identifies a physical attack vector but does not specify the exact boot media, configuration, or attacker-controlled input required to create the missing-file condition. The direct result is that live-boot may proceed without the expected signature-enforcement guarantee. The evidence does not identify a narrower function, source path, or module beyond live-boot, and it does not establish the full deployment scope.

The supplied attack assessment indicates physical reachability, low complexity, no required privileges, and no user interaction. The record does not establish a network attack path or describe exactly how an attacker supplies or alters the boot environment so that .verity is missing. Public-exploit and active-exploitation status are unknown; the supplied evidence does not confirm a public exploit or an active campaign. The required condition for the described bypass is that the .verity file is absent.

The confirmed technical outcome is that dm-verity signature protection can be bypassed when the .verity file is missing. This can reduce assurance that the root filesystem is checked against the expected signed root hash before use. The supplied assessment describes an integrity impact, while it does not identify a confidentiality or availability impact. Organisationally, systems may lose a layer of boot-trust protection, but the available evidence does not establish a compromise, a specific alteration, or exposure of every live-boot deployment.

This flaw can weaken operational trust in live images and boot media that are expected to receive dm-verity signature protection. If the expected signature check is not enforced, an organization may have less assurance that the root content being booted matches the intended signed state. This is particularly relevant to recovery media, deployment media, and environments that depend on immutable or measured boot assumptions. The supplied evidence identifies an integrity consequence but does not establish a confidentiality or availability consequence, a specific breach, or a named victim.

1. Apply an official Debian fix for live-boot when Debian documents a corrected revision or release. No fixed release or confirmed solution is present in the record.
2. Until a fix is confirmed, do not treat dm-verity-enforce-roothash-signature as sufficient assurance when the .verity file can be absent.
3. Use an independent, trusted image and root-filesystem verification process for security-sensitive boot media. This is a temporary risk-reduction measure, not a fix for the defect.
4. Do not assume that later or parallel release branches are unaffected. Verify each branch separately against Debian's documented correction.

1. Inventory systems and images that use Debian live-boot, then determine whether they correspond to the affected git revision beginning with ff8867c.
2. Review boot configuration and image-generation procedures to determine whether dm-verity-enforce-roothash-signature is enabled or otherwise relied upon.
3. Inspect each live image or boot medium for the presence of the .verity file. Its absence is the condition directly associated with the described bypass.
4. Independently verify the integrity of the image and root filesystem using a trusted verification process. This is a precautionary control, not a confirmed indicator of exploitation.
5. No specific log event, IOC, or telemetry pattern is provided. The absence of unusual logs does not demonstrate that a system is safe.