Will the ThreadX stack be updated to address the outstanding CVEs?

[Andrei Chichak]

There are a bunch of CVEs for ThreadX, NetX, and USBX dealing with remote code execution in versions below 6.2.1 (with some pretty scary vulnerability scores) and fixed in 6.3.

The distribution in the STM32Cube system is 6.2.0 today, and I was wondering if the ThreadX support people have the latest distribution integration on their stack?

Thanks,

Andrei

[Pavel A.]

@Andrei Chichak Imagine that they've updated to 6.3. The next day a new bunch of CVE will arrive. then what?

As soon as you get the project building, begin refactoring it to decouple ThreadX from the Cube package, so that ThreadX can be maintained independently. Change the source/include paths... Do the same for other 3rd party libraries.

 

[Andrei Chichak]

Assume that there is a release coming up from the Eclipse Foundation rather than Microsoft, it's imminent, real soon now. I expect that the appropriate staff are waiting for that to drop, with the 6.3 changes, before they prepare the port.

But to answer your question, if a new bunch of CVEs drop the next day, Microsoft (now Eclipse) prepares the new release, sends out notifications to the appropriate governmental and industry interested parties, then Eclipse ThreadX board members (like ST) determine when to release those changes through their internal processes. It shouldn't matter if there will be more CVEs dropping tomorrow, in Microsoft's case with Windows they decided to push daily and monthly updates, plus bundles. Other companies reach out and force updates. Others, like ATM manufacturers, just run Windows 95 and deal with the exposure. PVR and router manufacturers will just drop support for those models and move on. Others, like medical devices, have rules governing updates of COTS and they may choose to do nothing, they might have to notify the FDA/Health Canada/??? and prepare a plan to overcome the vulnerability, or may ask their customers to take their devices off-line, they may fly out techs to update the systems.

So, then what? It depends, there is not one answer.

[Andrei Chichak]

In today's email:

 

Dear all,

We have just published three CVEs for ThreadX (various modules)

 

CVE-2024-2212  HIGH Integer wraparounds, under-allocations, and heap buffer overflows in Eclipse ThreadX xQueueCreate() and xQueueCreate Set()

 

CVE-2024-2214  HIGH Missing array size check in _Mtxinit() in the Xtensa port

 

CVE-2024-2452  HIGH Integer wraparound, under-allocation, and heap buffer overflow in Eclipse ThreadX NetX Duo __portable_aligned_alloc()

 

All have been fixed in the 6.4.0 release.

 

Please note that the EF Security Team typically does not send such messages as the Project team decides on how to communicate, but those issues come from the backlog and the project is in the migration phase. So, I do send it out so that everyone is aware.

 

Kind regards,

Marta Rybczynska

Technical Program Manager, Security Team, Eclipse Foundation

A

[jerry_sandc]

I have a related questions for ST ..

Will https://github.com/STMicroelectronics/x-cube-azrtos-f7 be updated or replaced to incorporate https://github.com/eclipse-threadx?

Will the STM32CubeIDE and MX tools be updated to pull in latest (or selected) versions from  https://github.com/eclipse-threadx?

What's the plan in general?   I can't find any info from ST on the move from Azure RTOS to Eclipse ThreadX.

thx

 

[jerry_sandc]

Replying to myself here, we're moving away from using the x-cube-azrtos-f7, and now pulling from Eclipse github for ThreadX, etc directly.