How does Toradex handle U-Boot CVEs in current BSP releases (still 2024.x based)?

Technical Support
, ,
1

Hi Toradex team,

We build our own Yocto distribution (Scarthgap) for a family of measurement devices based on Verdin AM62 and Verdin iMX8M Plus modules, and we maintain light forks of the Toradex U-Boot trees (only a handful of board specific commits on top). As part of preparing for the EU Cyber Resilience Act we now run cve-check over every release, including the bootloader, and I would like to understand how Toradex approaches the U-Boot side of this.

What we observe

Looking at the release matrix, the current BSP 7.6.1 (May 2026) still ships:

  • Verdin AM62: downstream Toradex TI U-Boot 2024.04 (TI release 10.01.10)
  • Verdin iMX8M Plus: upstream based Toradex U-Boot 2024.07

Our own bases are the same generation (TI 2024.04 and NXP imx_lf 2024.04). When we scan them with CVE_PRODUCT = "denx:u-boot", cve-check reports 12 unpatched CVEs per module, 10 of them scored 7.0 or higher, for example:

CVE Area Fixed upstream in
CVE-2024-57254, CVE-2024-57255, CVE-2024-57258, CVE-2024-57259 SquashFS parsing 2025.01-rc1
CVE-2024-57256 ext4 ext4fs_read_symlink integer overflow 2025.01-rc1
CVE-2026-46728 FIT signature verification bypass 2026.04
CVE-2026-29008, CVE-2026-29009 U-Boot TCP receive path, NFS nfs_readlink_reply 2026.04-rc3 / 2026.07-rc2
CVE-2024-42040 net/bootp.c memory leak to the local network Still open upstream

To be clear, we do not think all of these are exploitable on our products. We triage them per product against the built U-Boot .config and the deployed boot environment: SquashFS, NFS and the U-Boot TCP stack are not enabled in our configurations, and our bootcmd chain never issues a network boot command, so those findings are documented as not affected with that evidence. What is left after triage is small but real, mainly the ext4 symlink overflow (we do load the kernel and device tree from an ext4 partition) and, on AM62 where CONFIG_FIT_SIGNATURE is enabled by the TI Kconfig chain, the FIT signature bypass.

What I would like to understand

  1. Backporting policy: Does Toradex track U-Boot CVEs for released BSPs and backport fixes into the downstream branches, or is the expectation that customers carry such patches themselves? We have not found CVE fix commits for the items above in the 2024.x branches.
  2. Newer U-Boot base: Are there plans for a BSP generation with a 2025.x or 2026.x U-Boot base, and if so, is there an indicative timeline? For the AM62 this presumably depends on the TI release cadence as well.
  3. Recommended approach in the meantime: For a customer who must self-assess, what would you recommend for the remaining applicable findings? Cherry picking the upstream fixes onto the Toradex branch looks like the lowest risk option to us, since moving to a mainline 2026.x base would mean leaving the supported downstream tree (TI K3 boot chain, DDR configuration, tdx-cfg-block, board support). We would prefer not to diverge from your tree if fixes are planned on our side.

Any insight into how Toradex manages this would be much appreciated.

Best regards,
Fide

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Hi Fide,

Thank you for the detailed question about U-Boot CVE handling in Toradex BSP releases. I understand your need to prepare for the EU Cyber Resilience Act and appreciate the thorough triage work you’ve already done.

Based on the available documentation, I can provide some context, though I don’t have specific information about Toradex’s CVE backporting policy for U-Boot in the sources provided.

What the Documentation Shows

The Toradex BSP documentation confirms that U-Boot is a core component of the boot process(1). For building U-Boot from source, Toradex provides guidance on obtaining the source code from their repositories and building custom versions(2).

Regarding security features, the meta-toradex-security layer documentation indicates that Toradex does provide security-focused capabilities including Secure Boot with bootloader signature checking(3). The layer supports “bootloader images are signed at build time and their signature is verified by the SoC ROM code at boot”(3) and “FIT image signature checking” where “a FIT image containing the kernel, device trees, and ramdisk is signed at build time and verified by the bootloader at boot”(3).

What I Cannot Confirm from Documentation

The available sources do not contain:

  • Specific CVE backporting policies for released BSP versions
  • Timelines for U-Boot version updates in future BSP releases
  • Official guidance on handling U-Boot CVEs in current 2024.x-based releases

Recommended Next Steps

Given the importance of your CRA compliance requirements and the specific technical questions you’ve raised, I recommend:

  1. Direct Technical Inquiry: Contact Toradex support through the Toradex Community with your specific CVE list and configuration details. The support team can provide authoritative guidance on their CVE handling approach.

  2. Security Layer Review: Review the meta-toradex-security layer documentation(3) to understand available security hardening options that may help mitigate some attack vectors, particularly around FIT signature verification.

  3. Build Your Own: Since you’re already maintaining light forks, the documentation supports building U-Boot from source(2), which would allow you to cherry-pick upstream CVE fixes while maintaining compatibility with Toradex-specific features like tdx-cfg-block.

Your assessment that cherry-picking upstream fixes onto the Toradex branch represents the lowest-risk approach seems reasonable from a technical standpoint, though official confirmation from Toradex would be valuable.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Hello @Fide,

As per new u-boot versions, the next BSP (8) will have newer u-boot versions for all SoMs.
The initial release is expected at the start of October 2026 and from what I have seen, most if not all boards should go to 2026.x u-boot versions, some still downstream and some upstream u-boot.

Regarding the broader topics and also generally how support for existing BSPs is handled when it comes to u-boot, I brought this up to our product security team.
Once we can bring a complete response on this topic, there will be an update here.

Best Regards,
Bruno

5

Hello @Fide,

I have discussed this internally and have more information to share.
The current status of u-boot on our releases is the following:

We don’t hand pick commits (or CVE patches) for backporting into our downstream branches unless they fix a bring-up or HW issue we’re facing.
On the other hand, we do take care to move to newer U-Boot releases on time.
For example, we are planning that all current TI-based modules will start using upstream U-Boot v2026.07 (this would include the FIT image signing fix mentioned here) in BSP8.
Thanks to TI’s nice upstream process, we can easily move to even newer usptream U-Boot releases afterwards and we decided it is not necessary to stick to TI’s downstream branches for the AM69, AM62P and AM62.
iMX6, iMX7 and iMX8MM and iMX8MP will also be using upstream U-Boot v2026.07 in BSP8.
Other iMX8 and the iMX9 modules will be using Toradex NXP downstream v2026.04.

That being said, this is something that we will continue to discuss internally and may change in the future.
What I would recommend for now is that you check whether specific vulnerabilities are exploitable according your product’s threat model and if so backport the relevant fixes to your builds.
I hope that we will be able to take care of some of this in the future as a baseline for our BSP, but this is still open to discussion internally.

Best Regards,
Bruno

6

Hello @Bruno,

Thank you for taking this internally, that is exactly the clarity we needed. Two things are settled on our side: on BSP 7.x we own the backporting, and the FIT signature fix arrives with upstream v2026.07 in BSP 8, so we can record a dated remediation for that CVE instead of carrying it as an accepted risk. Moving the TI based modules to upstream U-Boot is very welcome here.

Since the topic is still open internally, three points from a device manufacturer working under the Cyber Resilience Act:

  • Timing. A fix that exists only in the next BSP is not a fix we can ship next month. We do update our products in the field, U-Boot included, but adopting a new BSP means a new kernel, a new toolchain and a new U-Boot at once, so it lands as a major release with full validation rather than as a security update. In the interval, our own backport is the only lever we have.

  • A per BSP statement would help us more than backports would. Instead of hand picking commits, publishing which U-Boot CVEs Toradex considers not applicable to its own board defconfigs, and why, in the spirit of a VEX document. Every integrator repeats that same reachability analysis today, on the same boards and largely the same configuration, and none of us can see the others’ reasoning.

  • Does the CRA not apply to the modules themselves? We keep selling VF50 based products and expect to continue after December 2027, so we have to meet the CRA obligations for them. A Toradex module placed on the European Union market with U-Boot and a BSP on it looks like a product with digital elements in its own right, with the same duties around known exploitable vulnerabilities, a component list and a declared support period. I may well be missing something here, so I am genuinely asking rather than implying.

On Vybrid specifically:

  • It is not in the BSP 8 list, U-Boot is still 2015.04, so ten years of U-Boot CVEs are nominally open there and no vendor fix will ever arrive. I am not asking for the old support model back.

  • Upstream is not the blocker either. board/toradex/colibri_vf, configs/colibri_vf_defconfig and the vf610 SoC support are all still in U-Boot master and in v2026.04, the defconfig is driver model migrated, and the board MAINTAINERS entry still names Francesco Dolcini at Toradex.

  • The port has become cheap, including with AI help for the mechanical parts. We already run the Colibri VF50 on Yocto scarthgap with a mainline 6.12 kernel and have tested wrynose with a mainline 6.18 kernel, both fine in our testing. Only U-Boot is left standing in the past. If you picked up that one piece, even as a recipe pointing at upstream rather than a fully supported BSP, the portfolio would be complete.

Thanks again for chasing this down internally.

Best regards,
Fide

7

Hi,

have you considered using the vex-check instead of CVE-check to do your CVE reporting?

This is much more reliable than CVE-check which has to download new CVEs to a database which can fail silently.

Also, do you include the yocto CVE base config that adds relevant ignore statements for some CVEs as they are old, irrelevant or cannot be fixed.

This process gives you a simple summary (my latest build only shows 14 CVEs mostly in curl) and a manifest that contains only the packages installed in your actual image that is json and easily readable for the reason CVEs are ignored.

Our external security company are usually happy with this for CVE reporting on our products.

Regards, Izzy

8

Hello @Fide,

Regarding the VF50, it is a special case as its EOL will be before the CRA deadline of December 2027.
Please keep that in mind, as we will no longer ship those modules after the Last Time Ship of September 30th 2027.

The main reason for the EOL is the CRA, as we don’t think we can actually provide the product in a way that complies with it once it is in effect.
For the VF50 and VF61 SoCs, beyond the software side there are known hardware vulnerabilities with this platform.

Thanks for raising those points.
I agree that a fix in a next BSP is of limited help when you currently have a product in the current BSP.
I brought these points up in the internal discussions on the topic.
Once we have more information on how we will deal with this in the future, I will send an update here.

Best Regards,
Bruno

9

Hi @izzycoding,

Thanks for your input, I know that for Torizon OS we use VEX.
Regardless, I will bring this up in our internal discussion.

Best Regards,
Bruno

10

fyi
A recent Gartner First Take webinar (14 May 2026, “OpenAI Daybreak vs. Anthropic Mythos”) reframes exactly this debate: vulnerability discovery is now cheap, but the last three steps of the remediation chain — plan-patch, verify, deploy — are where all the friction lives, and the BSP model concentrates every one of them on Toradex.

The single highest-leverage artefact Toradex could publish per released BSP is a VEX statement covering the U-Boot CVEs in that BSP — marking each as not_affected (with justification), affected, or fixed — using the Torizon OS work as internal precedent.

Toradex could design an autonomous CVE self-patch appliance which allows devsecops teams to get out of saturation risks.

Every integrator currently redoes that triage independently, which is exactly the duplication VEX was designed to eliminate, and under CRA it is also the evidence trail a manufacturer of a “product with digital elements” will need regardless. Waiting for BSP 8 is defensible for functional bring-up; for CVE posture it is not.

1 Like
11

I’d like to respond to this question specifically:

Does the CRA not apply to the modules themselves? We keep selling VF50 based products and expect to continue after December 2027, so we have to meet the CRA obligations for them. A Toradex module placed on the European Union market with U-Boot and a BSP on it looks like a product with digital elements in its own right, with the same duties around known exploitable vulnerabilities, a component list and a declared support period. I may well be missing something here, so I am genuinely asking rather than implying.

The module and the BSP are separate things, treated quite differently under the CRA.

The module, and the software that ships on the module (Toradex Easy Installer), are indeed products placed on the EU market with accordant CRA responsibilities. However, the responsibilities for the software apply only to the intended use of the software we ship on the module, and that intended use is to allow you to install any other software you choose on it. As you can imagine, most vulnerabilities in the software components that make up Toradex Easy Installer are redundant when this purpose is considered.

Our BSP, however, is not shipped on the module, and is not “software placed on the market in the course of a commercial activity” as defined by the CRA and clarified in EU guidance documents. I’m quoting here from the draft version of the “Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)”, section 3.2.7 “Integration by other manufacturers”:

In some cases, a FOSS is published by a clearly identifiable natural or legal person, but that
FOSS is ‘intended for integration by other manufacturers into their own products with
digital elements’. In such cases, that FOSS is not considered to be placed on the EU market,
unless it is also monetised by the person that publishes it (i.e. the original manufacturer),
in line with previous sections of this guidance.

Where that FOSS is not placed on the market, the legal person publishing it would be
subject to the obligations of stewards, if it provides support on a sustained basis, in line
with the definition of ‘steward’.

So our CRA role with respect to our BSP layers is that of an Open Source Steward, with the reporting obligations defined in Article 24.