We wanted to get details on the FreeRToS v11.3.0
Can you let us know the license details and the SBOM report generated. Also is this MISRA C 2023 compliant, if do please share the report details.
While running SBOM analysis we see few licenses has reached its EOL how is this handled in your case. Please share the details on which MISRA C compliant and any documents related to this.
Here are the SBOM files:
As mentioned in this document, it is MISRA C2012 compliant. This document describes how to setup coverity for checking MISRA compliance.
Thanks for the response.
With this we could see there are few licenses which have reached its EOL. Based on our analysis here is the sample details which show as licenses which has reached EOL.
| Component | Version | License | EOL Status | Notes |
|---|---|---|---|---|
| FreeRTOS | 8.2.2 | MIT |  EOL |
Pre-LTS, obsolete |
| FreeRTOS | 9.0.0 | Modified GPL | EOL |
Non-LTS, unsupported |
| FreeRTOS | N/A | Modified GPL |  Unknown |
Need version clarity |
| FreeRTOS | 10.4.0 | MIT |  Supported* |
Likely still within maintenance window |
| FreeRTOS | 9.0.0-rc1 | MIT | EOL |
Pre-release version |
| FreeRTOS | 9.0.0-rc2 | MIT | EOL |
Pre-release version |
Please let us know what is the plan for this or is these kept with limitations in latest v11.3.0.
Is there any plan to check for MISRA C 2023 compliant. If so please let us know the ETA of the plan.
Also, I see that the LTS v11.3.0 is not Top 25 CWE compliant too. CWE-125 in /FreeRTOS/Source/tasks.c Line 3567 - Checker / Type is OVERRUN
| prvCreateIdleTasks | Overrunning array ““IDLE”” of 5 bytes at byte offset 7 using index “xIdleTaskNameIndex” (which evaluates to 7). | |
|---|---|---|
Can you please check this too and let know if this is CWE compliant
Note: v9.0.0 did not have this issue
These licenses are for previous versions of FreeRTOS. If you are using 11.3.0, why check for these licenses? How did you generate the data you shared below?
I do not see any issue here - FreeRTOS-Kernel/tasks.c at V11.3.0 · FreeRTOS/FreeRTOS-Kernel · GitHub. So this may be limitation of the tool you are using? Which tool are you using?
We are getting those information from our internal tool to get the SBOM details. This is the same observation with both versions v9.0.0, v11.1.0 and v11.3.0.
But the CWE issue is a concern here - because of this CWE-125 issue, this FreeRtos v11.3.0 is showing as not compliant for Top 25 CWE. Can you let us know if you have suppressed this issue or this has been fixed. This issue was not observed with v9.0.0
I do not see any occurrence of any of the versions you mentioned in your table above in this file. I am not sure how your tool is detecting those.
As I mentioned before, there is no issue - so the question of fixing or suppressing does not arise. Again, this seems to be a tool issue. You did not observe this in 9.0.0 because this code was not present in 9.0.0.
Hi,
We are using Coverity Static Analysis 2024.12.0 tool to check the MISRA C 2023 and Top 25 CWE compliance. From that we could see this version v11.3.0 has 0 Mandatory defects, but has countable Required and Advisory issues which can be ignored.
But when we analyze out CWE report it states that there is 1 violation in Top 10 and Top 25. Here is the summary
Can you please let us know if there is any Top 25 CWE analysis done from your end. Also, I would like to confirm that the issue is common with both 11.1.0 and 11.3.0
We might need to resolve this to claim our src as Top 25 CWE compliant and this is not a tool issue. Please share your thoughts on this.
Your table showing the license used by different FreeRTOS versions shows V8.x using MIT. That is wrong. From memory V10 was the first to use MIT. A change intended to make it easier for enterprises to use FrEeRTOS in their products.
Why do you list so many versions of FreeRTOS, some of which are very old? Which version do you intend using? It is strongly advised not to mix files from multiple versions, and generally if starting a new project, to select the latest version.
Our firmware uses FreeRTOS Kernel 11.3.0 only. It does not contain or use multiple FreeRTOS versions.
E.g:
• The Black Duck finding is a snippet match and does not confirm that FreeRTOS V9.0.0-rc2 is used in the firmware.
• The matched source content is common across FreeRTOS releases.
• The observed difference is primarily related to the FreeRTOS version information in the file header.
• The firmware source contains and uses FreeRTOS Kernel V11.3.0 only.
• No multiple FreeRTOS versions are included in the firmware source.
This can be ignored and we can proceed further but we wanted to know if there is any update on Top 25 CWE compliance
Would you please share how you concluded that? It would be best if you can link the line in code where you think the issue is.
We are using “Coverity Static Analysis 2024.12.0 tool” via Jenkins to run the CWE Top 25 Compliance analysis. If this is a tool issue, we might get that for other modules too but this is specific to this particular line.
Could you please share the Top 25 CWE Report which you have run so that it can help us to get more clarifictaion
As far as I am aware, we did not run it.
I am not sure - a tool issue can manifest in some specific cases. Are you willing to share the details from the tool which would enable us to determine the issue? If yes, please DM me and will try to find time to take a look at those.
As mentioned earlier we are using the Coverity Static Analysis 2024.12.0 to run CWE Top 25 compliance and generate the reports.
Please let know what other details you might need to support
As mentioned earlier we are using the Coverity Static Analysis 2024.12.0 to run CWE Top 25 compliance and generate the reports.
Please let know what other details you might need to support.
CWE/SANS Top 25 Remediation Resolve 1 issues that are present in the CWE/SANS Top 25.
See the CWE/SANS Top 25 Section for a list of them.
More details on the CWE/SANS Top 25 List - The SANS Institute is a cooperative research and education organization made up security experts from around the world. SANS is a major source of information on computer security and makes available an extensive collection of research documentation. It also operates the Internet’s early security vulnerability warning system, the Internet Storm Center. The 2023 CWE/SANS Top 25 Most Dangerous Software Errors is a list of the most common and critical errors that can lead to software vulnerabilities, as published by this organization
I think I understand now. The tool is complaining about reading past configIDLE_TASK_NAME which defaults to “IDLE”:
#define configIDLE_TASK_NAME "IDLE"
According to the C spec, string literals are always NULL terminated and this check will ensure that we do not read past the bounds. Unless you are attempting to define configIDLE_TASK_NAME to something other than a string literal (which you should not), it is not a problem.
You can suppress this warning in Coverity with the justification:
We do not define configIDLE_TASK_NAME, so it defaults to "IDLE". Per the C specification, string literals are always null-terminated, and a check within the prvCreateIdleTasks function ensures the loop breaks upon encountering a null character—guaranteeing it never reads past the bounds of the string.
Thank you for the detailed explanation and this makes sense and we will suppress using the Justification provided.
Thanks for the prompt response.