This page lists security related updates applied to the code bases. For a description of the coding, testing, memory safety proof
and security review standards used by the RTOS kernel, see the "Coding Standard, Testing and Style Guide
" page. The "code quality checklist"
at the bottom of the Long-Term Support
(LTS) page has that same information for the newer FreeRTOS Core
and FreeRTOS for AWS IoT
libraries - including Coverity scans.
FreeRTOS is SESIP level 2 and PSA level 2 certified.
Applied Security (APSEC) and penetration testing (pentest) services are provided by AWS.
11/12/2021 - FreeRTOS Kernel versions 10.2.0 to 10.4.5 (inclusive)
- ARMv7-M and ARMv8-M MPU ports: It is possible for an unprivileged task to raise its privilege
by calling the internal function
The public CVE record for this can be found at MITRE: CVE-2021-43997.
09/10/2021 - FreeRTOS Kernel versions 10.2.0 to 10.4.4 (inclusive)
- ARMv8-M secure-side port: It is possible for unwanted code already running in privileged mode on the non-secure
side of an ARM Cortex-M23 or Cortex-M33 processor to force a situation where it gains visibility of a secure-side stack frame.
Further, if unwanted code is able to execute between a secure function calling a non-secure function and that non-secure function
returns to the secure state, then it is possible for the unwanted code to manipulate a task into calling an arbitrary secure-side
Applications that only use FreeRTOS code on the non-secure side, such as those running third-party code on the secure-side,
are not affected. We are not aware of a method of using this issue to get unwanted code onto a device or inject code onto
the secure-side of the MCU.
We thank SI Labs for reporting this behavior to the FreeRTOS team.
12/15/2020 - FreeRTOS Kernel V10.4.2 and earlier
In heap2.c there is an unchecked possible addition overflow when calculating the size of the block of memory to be allocated that could result in the size overflowing and the allocation returning success but allocating only a fraction of the memory asked for. This will only affect code where the amount of memory being allocated is within 8 bytes of 4 GB.
In queue.c there is an unchecked possible addition overflow during queue allocation. This will only affect code where the size of the queue is within sizeof(queue_t) bytes of 4GB.
In stream_buffer.c there is an unchecked possible addition overflow during steam buffer creation. This will only affect code where the size of the stream buffer is within sizeof(StreamBuffer_t) bytes of 4GB.
FreeRTOS V10.4.3 and newer contains additional code that checks for and prevents these potential overflows.
The public CVE record for this can be found at MITRE: CVE-2021-31571, CVE-2021-31572, and CVE-2021-32020.
We thank the MSVR (Microsoft Security and Vulnerability Research) team for reporting these issues.
09/10/2021 - FreeRTOS+TCP V2.3.3 and earlier
- In BufferAllocation_2.c, there is an unchecked possible addition overflow
when calculating the size of the block of memory to be allocated for a network buffer that could result in the size
overflowing and the allocation returning success but allocating only a fraction of the memory asked for. With default
settings, this would only occur when attempting to allocate within 12 bytes of 4 GB.
We thank Bernard Lebel (RMDS Innovation) for reporting this potential issue.
08/21/2018 - FreeRTOS+TCP V2.0.7
Multiple security improvements and fixes in packet parsing routines, DNS caching, and TCP sequence number and ID generation.
Disable NBNS and LLMNR by default.
Add TCP hang protection by default.
We thank Ori Karliner of Zimperium zLabs Team for reporting these issues.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.