In the Linux kernel, a significant vulnerability has been resolved, specifically in the x86/fred architecture. The issue with the vulnerability stems from the indirect branch tracker (IBT) and how the WAIT_FOR_ENDBRANCH (WFE) state is handled.
To give some context, an indirect branch instruction sets the CPU's IBT into WFE state, and this WFE state remains asserted even across instruction boundaries. When the decoder encounters an inappropriate instruction while the WFE is set to ENDBR, the CPU raises a #CP fault. This behavior is the root of the vulnerability addressed through CVE-2024-56761.
In the "kernel IBT no ENDBR" selftest, where #CPs are intentionally triggered, the WFE state of the interrupted context must be cleared to allow for the execution to continue. If not, when the CPU resumes from the instruction that caused the prior #CP, another missing-ENDBRANCH #CP is raised, causing the CPU to enter a dead loop.
The IDT did not have this problem as it doesn't preserve the WFE state, and IRET does not set WFE. However, FRED provides space on the entry stack (within an expanded CS area) to save and restore the WFE state. As a result, the WFE state is not clobbered, necessitating software intervention to clear it.
Here's a code snippet that demonstrates how to clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the !ibt_fatal code path when execution is allowed to continue:
/* Clear WFE in missing-ENDBRANCH #CPs */
void ibt_clear_fred_wfe(void)
{
unsigned long fred_mask = X86_FRED_WFE;
asm volatile ("clrfred %" : : "m" (fred_mask));
}
It is crucial to note that clobbering WFE in any other situation constitutes a security-relevant bug.
For additional information on this vulnerability and its resolution, refer to the following original references:
- Linux Kernel Mailing List - Patch
- Linux Kernel Source Tree
This patch has resolved the vulnerability in the x86/fred section of the Linux kernel, effectively addressing CVE-2024-56761. Moving forward, kernel developers and users should ensure the deployment and usage of the patched version to maintain a secure environment.
Timeline
Published on: 01/06/2025 17:15:41 UTC
Last modified on: 01/07/2025 23:05:19 UTC