what is the current patchlevel of kernel 6.6 when using the YOCTO repo and building for colibri imx7d?
Hi, I’m the Toradex AI Assistant.
I might make mistakes or occasionally get you wrong. Our support team will step in if needed.
Looking at the available documentation, I can see information about kernel versions in the Yocto builds.
Based on the community forum discussion about BSP 7.0.0 builds, there is a reference to kernel version 6.6.23 being used in the build process(1). However, the sources don’t provide the complete current patchlevel information for kernel 6.6 specifically for the Colibri iMX7D when using the Yocto repo.
To get the exact current patchlevel information for your specific configuration, I’d recommend:
- Check your build configuration - After setting up your Yocto build environment, you can examine the kernel recipe files in the
meta-toradex-bsp-common/recipes-kernel/linux/directory - Review the SRCREV variable - As mentioned in the kernel patching documentation, the
SRCREVvariable points to the specific commit being used(2)
The manifests documentation explains that Toradex maintains official manifests at the toradex-manifest repository, with different manifest files for different release types (default.xml for monthly/quarterly releases, integration.xml for nightly releases)(3).
For the most accurate and current patchlevel information for your specific Colibri iMX7D build, you would need to check the actual kernel recipe files in your local Yocto build setup after following the repository initialization process.
Best regards, Toradex AI Assistant.
Did you like my answer? 
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
i know that i have 6.6.117 , but what is the current and when could i expect to get 6.6.120 without patching it myself?
I’d be glad to help! Could you let me know which OS and version you are using?
To provide accurate information about kernel updates and release timelines, I need to understand your specific platform setup. The kernel versions and update schedules vary significantly between different Toradex operating systems.
Could you please run the tdx-info command on your device and share the output? This will help me determine your exact hardware and OS configuration. You can find more information about this command at tdx-info documentation.
Once I know whether you’re using Torizon OS, BSP (Yocto), or another platform, I can provide specific guidance about kernel update expectations and release schedules.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Software summary
------------------------------------------------------------
Bootloader: U-Boot
Kernel version: 6.6.120-7.5.0-devel #1 SMP PREEMPT Mon Nov 24 09:30:14 UTC 2025
Kernel command line: ro rootwait console=tty1 console=ttymxc0,115200 root=PARTUUID=b3cf3371-02
Distro name: NAME="TDX Wayland with XWayland Upstream"
Distro version: VERSION_ID=7.5.0-devel-20260105082212-build.0
Distro variant: -
Hostname: -
------------------------------------------------------------
Hardware info
------------------------------------------------------------
HW model: Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version: 0039 V1.1B
Serial number: 12828752
Processor arch: armv7l
------------------------------------------------------------
Thank you for providing the tdx-info output! I can see you’re running a development build (7.5.0-devel) with kernel 6.6.120 on a Colibri iMX7D.
Current Kernel Status
Based on the Embedded Linux Release Matrix, the current production releases for Colibri iMX7 are(1):
- BSP 7.3.0: Kernel v6.6 (upstream based on kernel.org)
- BSP 6.8.3: Kernel v6.1.123 (upstream based on kernel.org)
Your development build shows kernel 6.6.120, which indicates you’re already running a relatively recent kernel version.
Release Timeline Expectations
The sources don’t provide specific timelines for when kernel 6.6.120 will be included in production releases. However, I can share what’s documented about Toradex’s release process:
Kernel Sources and Updates
For Colibri iMX7, Toradex uses upstream kernels based on kernel.org(1). The kernel compilation process involves cloning from the stable Linux kernel repository(2):
$ git clone -b <version> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Development vs Production Releases
Since you’re on a development build (7.5.0-devel), you’re likely getting newer kernel versions before they appear in stable production releases. Production releases typically follow a more structured schedule with thorough testing.
Recommendation
For the most current information about when kernel 6.6.120 will be available in production releases, I’d suggest checking the release notes and announcements as they become available, since the sources don’t contain specific future release timelines.
Best regards, Toradex AI Assistant.
Did you like my answer?
If I answered your question, please tick the “Solution” checkbox.
For follow-up questions to me, please use @ToradexAI in your post.
Dear @pfarre,
thank you for interacting with our Toradex AI. May I ask what the specific reason for the requirement of a newer kernel patch version is on your side? Does the one you are using currently have a bug or need fixing any way?
Best regards,
Collin
Hi Collin,
i still have open CVE’s that dont seem to be patched in 6.6.117 - some of them seem to be covered in 6.6.120. However if i apply the incremental patches in my own recipe, the cve-summary does not reflect the expected changes - but usually, when i fetch a new repo from you the results match the kernel patchlevel.
I might add that i also use the iris gmbh meta-cyclonedx layer to generate bom.json and vex.json files which are then loaded in dependency-track.
Best Regards
Paul
Dear @pfarre,
Thank you for your explanation. I have some additional questions to further our understanding to find a solution:
- What specific CVEs are you witnessing?
- What build versions are using here?
- Are you using the Torizon Cloud services?
- Which repo are you referring to (which repo-init command)?
Best regards,
Collin
Hi collin,
I am building the upstream distro tdx-reference-minimal-image for imx7D 1G eMMC YOCTO BSP 7.5.0 - following Toradex : Building with YOCTO
(i do see now, that its the monthly release that i fetch repo init -u git://git.toradex.com/toradex-manifest.git -b scarthgap-7.x.y -m tdxref/default.xml )
There are actually several open CVE’s (if im not mistaken).
One example based on : oe-core/build/tmp/log/cve/cve-summary.json
“id”: “CVE-2025-21786” , “status”: “Unpatched”
I expect that tmp/work-shared/colibri-imx7-emmc/kernel-source/kernel/workqueue.c should hold the actual source that is compiled - but it does not have the patch that was added to 6.12.16 which seems to confirm its unpatched inn 6.6.117.
Following are some of the concerned CVE’s (i list one file for reference, and the known patch if there is one)
CVE-2025-21786 kernel/workqueue.c [6.12.16][6.13.4]
CVE-2023-6931 kernel/events/core.c [6.7]
CVE-2025-22121 fs/ext4/inode.c [6.14.2] *** 6.6.120 ***
CVE-2024-53147 fs/exfat/namei.c [6.11.11][6.12.2]
CVE-2023-6531 net/core/scm.c io_uring/rsrc.h [6.7]
CVE-2025-38201 net/netfilter/nft_set_pipapo.c [6.12.35]
CVE-2025-38248 net/bridge/br_multicast.c [6.16.3] net bridge multicast
CVE-2025-38556 drivers/hid/hid-core.c [6.12.48] *** 6.6.119 ***
CVE-2025-38129 net/core/page_pool.c [6.12.43] *** 6.6.120 ***
CVE-2016-2568 polkit pkexec version 124 [fixed version=126, ok in Torizon]
2025-22121 and 2025-38129 patched in 6.6.120 , 2025-38556 in 6.6.119
I am not using the Torizon Cloud service.
Best Regards - Paul
For the upstream kernels, we bump to the latest SRCREV once per month. The most recent bump, from January 5, updated it to 6.6.119.
However if i apply the incremental patches in my own recipe, the cve-summary does not reflect the expected changes - but usually, when i fetch a new repo from you the results match the kernel patchlevel.
Do you mean that you extract the individual patches and apply them in your own recipe? Or do you bump the kernel recipe so that it fetches a more recent upstream SRCREV? The latter would be a better approach than patch-by-patch backporting of fixes.
Regarding the cve-summary results, please note that Yocto’s cve-check is far from perfect. For our internal vulnerability management for Torizon OS, we do quite a lot of additional processing, as well as human analysis, to arrive at a correct SBOM, VEX, and VDR. Some tips to increase the quality of your results when working with meta-cyclone-dx:
- If you apply individual patches for a CVE and you want it to show up in the results, there are a couple of distinct ways to make sure that’s visible to the cve-check class, and to the VEX file that meta-cyclonedx generates. First, the patch should be named
CVE-XXXX-YYYYY.patch. For the cve-check class, you can also make use of theCVE_STATUSvariable in the recipe where you apply the patch. Make sure you’re using the latest rev of meta-cyclonedx, as there have been some recent changes fixing bugs in the CVE patch matching. - To ensure the CPE is correct in the SBOM, make sure you set CVE_PRODUCT/CVE_VERSION if there’s any difference between the version set in PN/PV and the version that needs to appear in the CPE. That’s where meta-cyclonedx constructs the CPE from. We do this in our kernel recipes, setting CVE_VERSION based on LINUX_VERSION, so as long as you bump LINUX_VERSION it should be correct.
- Cleaning up the rest of the results, false positives, etc. is something you can take a number of approaches to. I’ve heard of people using SPDX_INCLUDE_SOURCES to help with this. Internally, my approach uses a number of open source tools. One thing that helps a lot is kmax; you can use this to create a satisfiability graph for source files included based on kernel config. (There’s enough complexity and edge cases here that it’s non-trivial; other attempts to classify based on just parsing makefiles will get enough stuff wrong that I find kmax with its formal correctness, even though it’s complex to learn, is the best tool for the job.)
- Use the kernel’s vulns repo as your source of truth for structured information on kernel vulnerabilities, rather than the NVD or similar. The info is richer and more accurate; it can take time for updates from there to actually make it into vulnerability DBs.
Hi jon,
thanks very much for the input.
I now changed the machine definition to use kernel 6.12(63) and so far everything builds and boots. Based on Dependency-Track (and NVD) That brings me down to 15 CVEs concerning the kernel, 1 for u-boot and 8 for other components. Most of the kernel related have known patches in 6.13 - 6.16 (according to NVD). I’ll keep an eye on the vulns repo as you suggested and the kernel patches on kernel.org.
Best Regards - Paul