Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - x86/sgxポイゾニングされたページの再利用の試みを阻止します TL;DRSGX ページのリクレイムはページにタッチして、そのコンテンツをセカンダリストレージにコピーします。SGX命令は、マシンチェックを丁寧に処理しません。それにも関わらず、既存の SGX コードはそれがポイズニングされたページを再利用しようとします。ポイズニングされたページを回収しようとするのだけでも避けます。長い事例: エンクレーブによって使用されるページは、arch_memory_failure() で設定された epc_page->poison のみを取得しますが、現在は sgx_encl_release() まで sgx_active_page_list に留まります。SGX_EPC_PAGE_RECLAIMER_TRACKED フラグはタッチされません。 epc_page->poison がリクレイマーロジックでチェックされません。これは、他の条件が満たされた場合、ポイゾニングされた EPC ページの回収が試行されることを意味します。これは不適切です。1. ページが他のエンクレーブに追加されることを避け、2. 1 つのコアがシャットダウンし、カーネルがパニックになる可能性があるためです。具体的には、リクレイムには EWB を含むマイクロコード操作が使用されます。これは、EPC ページのコンテンツにアクセスして暗号化し、SGX 以外のメモリに書き出すものです。これらの操作は、実行中のコアを特別なシャットダウン状態にする以外のアクセスで MCE を処理できませんHT の両方のスレッドに影響。その後、カーネルは、コアが MCE ハンドラーに入力しなかったことを確認して、残りのコアでパニックになります発見しました。sgx_unmark_page_reclaimable() を呼び出して、メモリエラーで sgx_active_page_list から影響を受ける EPC ページを削除し、再利用を検討しないようにします。sgx_reclaim_pages() の epc_page->poison のテストも機能する可能性がありますが、可能性が低いパスにコードを追加する方が良いと考えられます。影響を受ける EPC ページは、それが EREMOVEd である場合、sgx_encl_release()->sgx_free_epc_page() で、&node->sgx_poison_page_list に追加されません。他のリストのメンバーシップは、sgx_active_page_list を除いて、リストのセマンティックの変更を回避するために変更されません。arch_memory_failure() には、プリエンプティブなアクションについての TBD コメントがあります。ここでの目標は、潜在的なすべてに対応することではありません。これはまた、メモリエラー通知が致命的になるときに時間ウィンドウを完全に閉じません (以前はポイゾニングされていない EPC ページの場合) -- MCE は、sgx_reclaim_pages() がその候補を選択した後、あるいはマイクロコード操作の *内部*で発生する可能性がありますそれらに費やされる時間のためにトリガーするのが実際には簡単です。memory_failure() がプロセスコンテキストで実行されスピンロックが保持されないため、sgx_unmark_page_reclaimable() のスピンロックは安全です。これは mm/memory-failure.c コメントで明示的に言及されています。
    (CVE-2025-38334)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its     contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the     existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim     poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in     arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the     SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic     meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was     poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is     likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode     operations including EWB which accesses the EPC page contents to encrypt and write them out to non-SGX     memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core     into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the     remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to     remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for     reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to     add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until     later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't     change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a TBD     comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything     that it may imply. This also doesn't completely close the time window when a memory error notification     will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has     selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount     of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure()     runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment.
    (CVE-2025-38334)

Note that Nessus relies on the presence of the package as reported by the vendor.

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - x86/sgx防止嘗試回收受害頁面 TL;DR: SGX 頁面回收會接觸頁面以將其內容複製到次要儲存裝置。SGX 指示未適當處理機器檢查。儘管如此現有的 SGX 程式碼仍會嘗試回收它知道已感染的頁面。甚至避免嘗試回收受毒害的頁面。詳細資訊enclave 使用的頁面只會在 arch_memory_failure() 中取得 epc_page->poison 集但目前在 sgx_encl_release() 之前它們會停留在 sgx_active_page_list 上且 SGX_EPC_PAGE_RECLAIMER_TRACKED 旗標不受影響。回收程式邏輯中並未檢查 epc_page->poison這表示如果符合其他條件則會嘗試回收遭到破壞的 EPC 頁面。這很糟糕因為 1.我們不希望該頁面最後被新增到另一個 enclave 以及 2.這可能會造成一個核心關機及核心錯誤。具體而言回收使用包含 EWB 的微碼作業其會存取 EPC 頁面內容以加密並將其寫出至非 SGX 記憶體。這些作業只能將執行中的核心置於特殊的關機狀態 (使用 HT 影響兩個執行緒) 才能處理其存取中的 MCE。隨後在其餘核心上發現核心未進入 中的 MCE 處置程式之核心時間。呼叫 sgx_unmark_page_reclaimable()從 sgx_active_page_list on memory 錯誤中移除受影響的 EPC 頁面以停止考慮對其進行回收。測試 sgx_reclaim_pages() 中的 epc_page->poison 亦可運作但我假設還是在不太可能的路徑新增程式碼比較好。受影響的 EPC 頁面在執行 EREMOVEd 時直到稍後在 sgx_encl_release()->sgx_free_epc_page() 中之後才會新增至 &node->sgx_poison_page_list。其他清單上的成員資格不會變更以避免變更任何清單的語意 (sgx_active_page_list 除外)。在 arch_memory_failure() 中有一個有關先佔式動作的待定註解其目的並非解決其可能隱含的所有問題。當記憶體錯誤通知將是嚴重的 (對於之前未毒害的 EPC 頁面) 時這也不會完全關閉時間範圍 -- MCE 可能發生在 sgx_reclaim_pages() 已選取其候選者之後甚至「內部」微碼作業 ( sgx_unmark_page_reclaimable() 中的 spinlock 是安全的因為 memory_failure() 在處理程序內容中執行且沒有保留任何 spinlocks這點在 mm/memory-failure.c 註解中有明確說明。
    (CVE-2025-38334)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - x86/sgx阻止尝试回收中毒的页面 TL;DRSGX 页面回收会接触页面以将其内容复制到辅助存储。SGX 指令未妥善处理计算机检查。尽管如此现有 SGX 代码仍将尝试回收它_知道_中毒的页面。避免尝试回收中毒的页面。长篇大论： enclave 使用的页面在 arch_memory_failure() 中只会获得 epc_page->poison 集但目前会在 sgx_encl_release() 之前留在 sgx_active_page_list 上同时 SGX_EPC_PAGE_RECLAIMER_TRACKED 标记未受影响。未在回收程序逻辑中检查 epc_page->poison这意味着如果满足其他条件将尝试回收中毒的 EPC 页面。这是因为 1. 我们不希望该页面最终被添加到另一个 enclave 以及 2. 它可能造成一个核心关闭及内核错误。具体来说，回收使用了微码操作，其中包括 EWB，该操作会访问 EPC 页面内容以对其进行加密，并将其写入非 SGX 内存中。那些操作无法处理其访问权限中的 MCE除非将执行核心置于特殊关闭状态影响两个具有 HT 的线程。随后内核将在剩余核心上发生错误因为核心未在 in 中进入 MCE 处理程序time。当内存出错时调用 sgx_unmark_page_reclaimable()从 sgx_active_page_list 中删除受影响的 EPC 页面以停止考虑对其进行回收。在 sgx_reclaim_pages() 中测试 epc_page->poison 也可以工作但我认为最好在不太可能的路径中添加代码。受影响的 EPC 页面直到稍后在 sgx_encl_release()->sgx_free_epc_page() 中进行 EREMOVEd 时才会添加到 &node->sgx_poison_page_list。其他列表上的成员资格不会变更以避免更改任何列表的语义除 sgx_active_page_list 外。在 arch_memory_failure() 中有一条关于 pre-emptive 操作的 TBD 注释其目标并非解决它可能暗示的所有问题。这也不会完全关闭时间窗口当内存错误通知将是致命的对于之前未中毒的 EPC 页面 -- MCE 可能在 sgx_reclaim_pages() 选择其候选之后发生甚至是在微代码操作 (实际上很容易触发因为花费在其中的时间。sgx_unmark_page_reclaimable() 中的旋转锁是安全的因为 memory_failure() 在进程上下文中运行并且不保留旋转锁这一点在 mm/memory-failure.c 注释中明确指出。
    (CVE-2025-38334)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

ID	Name	Product	Family	Published	Updated	Severity
244388	Linux Distros のパッチ未適用の脆弱性: CVE-2025-38334	Nessus	Misc.	8/6/2025	8/6/2025	medium
244388	Linux Distros Unpatched Vulnerability : CVE-2025-38334	Nessus	Misc.	8/6/2025	8/6/2025	medium
244388	Linux Distros 未修補的弱點：CVE-2025-38334	Nessus	Misc.	8/6/2025	8/6/2025	medium
244388	Linux Distros 未修补的漏洞：CVE-2025-38334	Nessus	Misc.	8/6/2025	8/6/2025	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium