Hi
We found an integer overflow vulnerability in the memory allocation function of your company's Processor SDK.
https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/kernel/nortos/dpl/common/HeapP_internal.c (Line 137)
In the source code of the pvHeapMalloc function, when wantedSize is incremented, the integer overflow problem is not considered. When wantedSize passes a very large value, such as 0xFFFFFFFF, the actual size obtained is the value of xHeapStrucSize-1.
When a user requests an unreasonably large amount of memory space, a pointer to a very small amount of memory space will eventually be returned to the user.
Suggested Fix
You can refer to the fix for integer overflow in pvPortMalloc in FreeRtos before. (CVE-2021-31571, CVE-2021-31572)
Before it does the self-increment, it checks whether it will overflow after adding ( portBYTE_ALIGNMENT – ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ).
Hi
We found an integer overflow vulnerability in the memory allocation function of your company's Processor SDK.
https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/kernel/nortos/dpl/common/HeapP_internal.c (Line 137)
In the source code of the pvHeapMalloc function, when wantedSize is incremented, the integer overflow problem is not considered. When wantedSize passes a very large value, such as 0xFFFFFFFF, the actual size obtained is the value of xHeapStrucSize-1.
When a user requests an unreasonably large amount of memory space, a pointer to a very small amount of memory space will eventually be returned to the user.
Suggested Fix
You can refer to the fix for integer overflow in pvPortMalloc in FreeRtos before. (CVE-2021-31571, CVE-2021-31572)
Before it does the self-increment, it checks whether it will overflow after adding ( portBYTE_ALIGNMENT – ( xWantedSize & portBYTE_ALIGNMENT_MASK ) ).