本文へ移動
English version →
高 8.5

Eclipse ThreadX でモジュールのオブジェクト解放により使用中のカーネルオブジェクトが解放される脆弱性

CVE-2026-94192 SecPulse初出

概要

Eclipse ThreadX では、モジュールが txm_module_object_deallocate でカーネルオブジェクトの管理領域を解放すると、カーネルが使用中の制御ブロックまで解放される問題があります。解放後のメモリが別の割り当てに再利用されるため、カーネルの動作が不安定になるおそれがあります。影響を受けるのは 6.0.1 から 6.5.1.202602a までの版です。最新の情報を確認してください。

AI要約

外部の AI が作成した要約です。誤りを含むことがあります。重要な判断の前に、下の原文と参照URLを確認してください。

Eclipse ThreadX では、モジュールが txm_module_object_deallocate でカーネルオブジェクトの管理領域を解放すると、カーネルが使用中の制御ブロックまで解放される問題があります。解放後のメモリが別の割り当てに再利用されるため、カーネルの動作が不安定になるおそれがあります。影響を受けるのは 6.0.1 から 6.5.1.202602a までの版です。最新の情報を確認してください。

影響パッケージ

種類パッケージ影響を受ける版直った版
Eclipse Foundation Eclipse ThreadX
6.0.1 〜 6.5.1.202602a
—
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with txm_module_object_deallocate. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.

出典: NIST National Vulnerability Database NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく