V10.4.3-LTS-Patch-3
版本发布时间: 2022-09-17 02:21:31
FreeRTOS/FreeRTOS-Kernel最新发布版本:V11.1.0(2024-04-22 15:38:26)
Changes between FreeRTOS V10.4.3 LTS Patch 2 and FreeRTOS V10.4.3 LTS Patch 3 released September 16 2022
+ ARMv7-M and ARMv8-M MPU ports: It was 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. A check has been added to
ensure that passing a negative argument as the xIndex parameter does not
cause arbitrary read or write.
We thank Certibit Consulting, LLC for reporting this issue.
+ ARMv7-M and ARMv8-M MPU ports: It was 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. MPU_xTaskCreate
and MPU_xTaskCreateStatic have been updated to only allow creation of
unprivileged tasks. MPU_xTimerCreate, MPU_xTimerCreateStatic and
MPU_xTimerPendFunctionCall APIs have been removed.
We thank Huazhong University of Science and Technology for reporting
this issue.
+ ARMv7-M and ARMv8-M MPU ports: It was possible for a third party that
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.
The local stack variable `xRunningPrivileged` has been removed so that
a manually crafted stack frame cannot be used for privilege escalation
by branching directly inside a FreeRTOS MPU API wrapper.
We thank Certibit Consulting, LLC, Huazhong University of Science and
Technology and the SecLab team at Northeastern University for reporting
this issue.
+ ARMv7-M MPU ports: It was possible to configure overlapping memory
protection unit (MPU) regions such that an unprivileged task could access
privileged data. The kernel now uses highest numbered MPU regions for
kernel protections to prevent such MPU configurations.
We thank the SecLab team at Northeastern University for reporting this
issue.