-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LTS Updates #562
Merged
Merged
LTS Updates #562
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ARMv7-M allows overlapping MPU regions. When 2 MPU regions overlap, the MPU configuration of the higher numbered MPU region is applied. For example, if a memory area is covered by 2 MPU regions 0 and 1, the memory permissions for MPU region 1 are applied. We use 5 MPU regions for kernel code and kernel data protections and leave the remaining for the application writer. We were using lowest numbered MPU regions (0-4) for kernel protections and leaving the remaining for the application writer. The application writer could configure those higher numbered MPU regions to override kernel protections. This commit changes the code to use highest numbered MPU regions for kernel protections and leave the remaining for the application writer. This ensures that the application writer cannot override kernel protections. We thank the SecLab team at Northeastern University for reporting this issue. Signed-off-by: Gaurav Aggarwal <[email protected]>
This commit makes the privileged RAM and stack regions non-executable. Signed-off-by: Gaurav Aggarwal <[email protected]>
It was possible for a third party that had 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. This commit removes the local stack variable `xRunningPrivileged` 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. Signed-off-by: Gaurav Aggarwal <[email protected]>
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. This commit ensures that MPU_xTaskCreate and MPU_xTaskCreateStatic can only create unprivileged tasks. It also removes the following APIs: 1. MPU_xTimerCreate 2. MPU_xTimerCreateStatic 3. MPU_xTimerPendFunctionCall We thank Huazhong University of Science and Technology for reporting this issue. Signed-off-by: Gaurav Aggarwal <[email protected]>
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. This commit adds checks 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. Signed-off-by: Gaurav Aggarwal <[email protected]>
Signed-off-by: Gaurav Aggarwal <[email protected]>
Signed-off-by: Gaurav Aggarwal <[email protected]>
Signed-off-by: Gaurav Aggarwal <[email protected]>
amazonKamath
approved these changes
Sep 16, 2022
RichardBarry
approved these changes
Sep 16, 2022
RichardBarry
requested changes
Sep 16, 2022
History.txt
Outdated
@@ -1,5 +1,30 @@ | |||
Documentation and download available at https://www.FreeRTOS.org/ | |||
|
|||
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 is possible for a third party that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The history file should make it clear these issues applied to the prior version. So "it was possible", rather than "is possible", as a minimum.
Signed-off-by: Gaurav Aggarwal <[email protected]>
RichardBarry
approved these changes
Sep 16, 2022
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR address the following issues:
xIndex
parameter topvTaskGetThreadLocalStoragePointer()
orvTaskSetThreadLocalStoragePointer()
respectively. We thank Certibit Consulting, LLC for reporting this issue.MPU_xTaskCreate
,MPU_xTaskCreateStatic
,MPU_xTimerCreate
,MPU_xTimerCreateStatic
, orMPU_xTimerPendFunctionCall
. We thank Huazhong University of Science and Technology for reporting this issue.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.