On Tue, Sep 08, 2026 at 09:27:03AM +1200, Eva Crystal wrote:
> Hi,
>
> Reporting a fail-open condition in FIT signature enforcement. I am
> sending this to the list per doc/develop/security.rst. I am not
> claiming a remote exploit here; the issue is that the verification
> gate silently reports success in a state an integrator can reach by
> mistake, with no runtime indication. Details below so you can judge
> the severity yourselves.
>
> Confirmed at commit b4ac71db (2026-09-07).
>
> Summary
> -------
>
> Both required-signature gates return success when the U-Boot control
> devicetree contains no /signature node. Verified boot is then
> effectively disabled, and the only indication is a debug() message
> that is compiled out in a normal build.
>
> Affected code
> -------------
>
> boot/image-fit-sig.c, fit_image_verify_required_sigs():
>
> /* Work out what we need to verify */
> *no_sigsp = 1;
> key_node = fdt_subnode_offset(key_blob, 0, FIT_SIG_NODENAME);
> if (key_node < 0) {
> debug("%s: No signature node found: %s\n", __func__,
> fdt_strerror(key_node));
> return 0;
> }
>
> boot/image-fit-sig.c, fit_config_verify_required_keys():
>
> /* Work out what we need to verify */
> key_node = fdt_subnode_offset(key_blob, 0, FIT_SIG_NODENAME);
> if (key_node < 0) {
> debug("%s: No signature node found: %s\n", __func__,
> fdt_strerror(key_node));
> return 0;
> }
>
> In the configuration path, reqd_sigs also stays at 0, so the closing
> check
>
> if (reqd_sigs && !verified)
>
> never fires either.
>
> Why this is not caught downstream
> ---------------------------------
>
> In boot/image-fit.c, fit_image_verify_with_data() the per-signature
> result is deliberately non-fatal:
>
> /*
> * Show an indication on failure, but do not return
> * an error. Only keys marked 'required' can cause
> * an image validation failure. See the call to
> * fit_image_verify_required_sigs() above.
> */
> if (ret)
> puts("- ");
> else
> puts("+ ");
>
> That comment is correct, and it is exactly what makes the missing node
> fatal to the security property rather than to the boot: with no
> /signature node there are no required keys, so nothing in the chain
> can produce a failure. A FIT image with absent, malformed or invalid
> signatures verifies successfully and the function returns 1.
>
> Threat model
> ------------
>
> To be straightforward about the ceiling: the control DTB is U-Boot's
> own, so an attacker who can rewrite it can generally rewrite U-Boot
> too, and in that case this adds nothing. The realistic exposure is
> different:
>
> - A build or integration mistake that omits the /signature node
> produces a board that boots unsigned images and prints nothing
> unusual. There is no boot-time signal that verified boot is off.
> - Platforms that keep the control DTB in a separate flash region
> with weaker write protection than the U-Boot image itself.
> - Downgrade of a correctly built device to an earlier DTB that
> predates signing.
>
> In all three the failure is silent, which is the part I think is worth
> changing regardless of how you rate the first point.
>
> Suggested fix
> -------------
>
> Minimally, raise the visibility: replace the debug() calls with
> printf() so a missing /signature node is announced on the console when
> FIT_SIGNATURE is enabled.
>
> Better, make it fail closed under a Kconfig option, defaulting on for
> FIT_SIGNATURE builds:
>
> if (key_node < 0) {
> printf("%s: No signature node in control FDT - "
> "verified boot is not enforced\n", __func__);
> if (IS_ENABLED(CONFIG_FIT_SIGNATURE_STRICT))
> return -ENOENT;
> return 0;
> }
>
> I am happy to prepare the patch for whichever form you prefer, and to
> add a test under test/py covering the missing-node case.
>
> Disclosure and CVE
> ------------------
>
> I understand from doc/develop/security.rst that the project does not
> assign CVEs. I originally documented this finding in February 2026.
> I am happy to follow whatever timeline you prefer for public
> disclosure, and will coordinate any CVE request separately rather than
> making it a precondition for the fix.Hello. Yes, please follow https://docs.u-boot-project.org/en/latest/develop/sending_patches.html and provide a fix and test for this issue, thanks! -- Tom
signature.asc
Description: PGP signature
