Wind River Support Network

Description

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

CREATE(Triage):(User=admin) [CVE-2025-38334 (https://nvd.nist.gov/vuln/detail/CVE-2025-38334)