Download FreeRTOS
 

Quality RTOS & Embedded Software

SECURITY
WHAT'S NEW
Simplifying Authenticated Cloud Connectivity for Any Device.
Designing an energy efficient and cloud-connected IoT solution with CoAP.
Introducing FreeRTOS Kernel version 11.0.0:
FreeRTOS Roadmap and Code Contribution process.
OPC-UA over TSN with FreeRTOS.

Security Practices

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 1 certified.

Applied Security (APSEC) and penetration testing (pentest) services are provided by AWS.

Security Related Blogs


Security Updates

FreeRTOS Kernel

09/16/2022 - FreeRTOS Kernel MPU ports all versions up to 10.4.6 (inclusive)

FreeRTOS V10.5.0 and newer contain additional code that checks for and prevents the issues listed below. The changes are also included in Long Term Support (LTS) release versions starting with V10.4.3-LTS-Patch-3.
  • ARMv7-M and ARMv8-M MPU ports: It is possible for a third party that has already independently gained the ability to execute injected code to achieve further privilege escalation by branching directly inside a FreeRTOS MPU API wrapper function with a manually crafted stack frame.

    Affects FreeRTOS Kernel MPU ports, versions 6.0.0 to 10.4.6 (inclusive).

We thank Certibit Consulting, LLC, the IoTSP Lab at Huazhong University of Science and Technology, and the SecLab team at Northeastern University for reporting this issue.
  • ARMv7-M and ARMv8-M MPU ports: It is possible for a third party that already independently gained the ability to execute injected code to read from or write to arbitrary addresses by passing a negative argument as the xIndex parameter to pvTaskGetThreadLocalStoragePointer() or vTaskSetThreadLocalStoragePointer respectively.

    Affects FreeRTOS Kernel versions 8.2.1 to 10.4.6 (inclusive).

We thank Certibit Consulting, LLC for reporting this issue.
  • ARMv7-M MPU ports: It is possible to configure overlapping memory protection unit (MPU) regions such that an unprivileged task can access privileged data.

    Affects FreeRTOS Kernel MPU ports, versions 6.0.0 to 10.4.6 (inclusive).

We thank the SecLab team at Northeastern University for reporting this issue.
  • ARMv7-M and ARMv8-M MPU ports: It is possible for an unprivileged task to invoke any function with privilege by passing it as a parameter to MPU_xTaskCreate, MPU_xTaskCreateStatic, MPU_xTimerCreate, MPU_xTimerCreateStatic, or MPU_xTimerPendFunctionCall.

    Affects FreeRTOS Kernel MPU ports, versions 6.0.0 to 10.4.6 (inclusive).

We thank the IoTSP Lab at Huazhong University of Science and Technology for reporting this issue.


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 xPortRaisePrivilege.

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 function.

    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.


FreeRTOS-Plus-TCP

09/10/2021 - FreeRTOS-Plus-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-Plus-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.