Re: [PATCH v2] Documentation: migration-guides: mention possible FIT compat break

[Sascha Hauer <s.hauer@pengutronix.de>]

On Thu, Apr 16, 2026 at 05:34:37PM +0200, Ahmad Fatoum wrote:
> With manually written ITS, it's easy to omit signing some of the images.
> This flew under the radar so far, but with v2026.03.0 (or v2025.09.3),
> this will lead to verification failure.
> 
> The security advisory has been updated, but it's nonetheless worth an
> addition to the migration guide.
> 
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> v1 -> v2:
>   - add same notice for v2025.09.3 as well
> ---
>  .../migration-guides/migration-2025.09.3.rst  | 21 +++++++++++++++++++
>  .../migration-guides/migration-2026.03.0.rst  | 19 +++++++++++++++++
>  2 files changed, 40 insertions(+)
>  create mode 100644 Documentation/migration-guides/migration-2025.09.3.rst
> 
> diff --git a/Documentation/migration-guides/migration-2025.09.3.rst b/Documentation/migration-guides/migration-2025.09.3.rst
> new file mode 100644
> index 000000000000..7fbea78a46d0
> --- /dev/null
> +++ b/Documentation/migration-guides/migration-2025.09.3.rst
> @@ -0,0 +1,21 @@
> +Release v2025.09.3
> +==================
> +
> +FIT Images
> +----------
> +
> +The fix for `CVE-2026-33243 <https://nvd.nist.gov/vuln/detail/CVE-2026-33243>`_
> +has the side effect that barebox after v2026.03.0 will not boot a signed

Shouldn't we mention the corresponding stable versions here?

> +configuration that excludes some images from the signature.
> +
> +Previously, it was possible to generate readily exploitable FIT images
> +by omitting them from ``sign-images`` in the ITS.
> +
> +If a FIT fails to boot with **v2026.03.1**, when it succesfully booted
> +v2026.02.0 or earlier, it's likely that it was vulnerable even without

and here?

Sascha

> +knowledge of CVE-2026-33243.
> +
> +Recommendation is to not write FIT ITS manually, but to use higher level
> +tooling that generates the ITS and feeds it to ``mkimage(1)``.
> +
> +For more details, refer to the `security advisory <https://github.com/barebox/barebox/security/advisories/GHSA-3fvj-q26p-j6h4>`_.
> diff --git a/Documentation/migration-guides/migration-2026.03.0.rst b/Documentation/migration-guides/migration-2026.03.0.rst
> index 1bd06ac7b743..f23001886b8b 100644
> --- a/Documentation/migration-guides/migration-2026.03.0.rst
> +++ b/Documentation/migration-guides/migration-2026.03.0.rst
> @@ -8,3 +8,22 @@ On NXP i.MX8MP the SoC UID was read out wrong. It really is 128bit from which
>  barebox only read 64bit. barebox now does it correctly, but rolled out devices
>  might depend on the SoC UID being constant. In that case
>  CONFIG_ARCH_IMX8MP_KEEP_COMPATIBLE_SOC_UID should be enabled.
> +
> +FIT Images
> +----------
> +
> +The fix for `CVE-2026-33243 <https://nvd.nist.gov/vuln/detail/CVE-2026-33243>`_
> +has the side effect that barebox after v2026.03.0 will not boot a signed
> +configuration that excludes some images from the signature.
> +
> +Previously, it was possible to generate readily exploitable FIT images
> +by omitting them from ``sign-images`` in the ITS.
> +
> +If a FIT fails to boot with **v2026.03.1**, when it succesfully booted
> +v2026.02.0 or earlier, it's likely that it was vulnerable even without
> +knowledge of CVE-2026-33243.
> +
> +Recommendation is to not write FIT ITS manually, but to use higher level
> +tooling that generates the ITS and feeds it to ``mkimage(1)``.
> +
> +For more details, refer to the `security advisory <https://github.com/barebox/barebox/security/advisories/GHSA-3fvj-q26p-j6h4>`_.
> -- 
> 2.47.3
> 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |