* [PATCH v2] Documentation: migration-guides: mention possible FIT compat break
@ 2026-04-16 15:34 Ahmad Fatoum
2026-04-17 9:14 ` Sascha Hauer
0 siblings, 1 reply; 2+ messages in thread
From: Ahmad Fatoum @ 2026-04-16 15:34 UTC (permalink / raw)
To: barebox; +Cc: str, Ahmad Fatoum
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
+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>`_.
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v2] Documentation: migration-guides: mention possible FIT compat break
2026-04-16 15:34 [PATCH v2] Documentation: migration-guides: mention possible FIT compat break Ahmad Fatoum
@ 2026-04-17 9:14 ` Sascha Hauer
0 siblings, 0 replies; 2+ messages in thread
From: Sascha Hauer @ 2026-04-17 9:14 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox, str
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 |
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-04-17 9:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-16 15:34 [PATCH v2] Documentation: migration-guides: mention possible FIT compat break Ahmad Fatoum
2026-04-17 9:14 ` Sascha Hauer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox