---

Introduction

In early 2024, security researchers uncovered a subtle yet critical flaw in the x86 implementation of the Linux kernel, affecting systems that use Indirect Branch Tracking (IBT) with the FRED (Flexible Return and Event Delivery) mechanism. This vulnerability—CVE-2024-56761—centers around improper clearing of the WAIT_FOR_ENDBRANCH (WFE) state, leading to potential denial of service through a repeat #CP fault (Control-Protection exception).

This post breaks down the issue in plain English, walks through the relevant Linux kernel code, explains the root cause, and explores how attackers might exploit the unpatched kernel.

What Is IBT and WFE on x86?

Indirect Branch Tracking (IBT) is an Intel processor security feature that helps prevent certain control-flow hijacks. IBT marks legal indirect branch targets with a special ENDBR instruction. If an indirect branch lands somewhere lacking ENDBR, the processor's Indirect Branch Tracker (IBT) enters a special state called WAIT_FOR_ENDBRANCH (WFE). If, while in WFE, the CPU encounters a non-ENDBR instruction, it triggers a #CP (Control-Protection) exception.

Normally, after a #CP, the processor expects software to gently handle and resolve the error, but trouble brews if the state persists...

The Vulnerability: WFE Not Cleared, #CP Dead Loop

Problem in Simple Terms: In the FRED-enabled Linux kernel, when a #CP is intentionally triggered (e.g., for self-testing, or accidentally by a buggy program), the kernel may fail to clear the WFE state before resuming execution. If that happens, the resumed code hits the same spot, another #CP triggers, and this repeats forever—locking up the process or potentially the whole system.

Why? Because under FRED, the WFE state is preserved across exception handling, whereas previous mechanisms (like the Interrupt Descriptor Table/IDT) would lose or reset it.

With FRED, WFE from a previous context is restored after handling an exception.

- If we don't explicitly clear WFE on #CP, execution resumes right back into a WFE context at code without ENDBR, instantly raising another #CP.

Fix in the Kernel

The Linux team patched this by explicitly clearing the WFE state during #CP (#Control-Protection) handling if it's not a fatal IBT violation, so execution can safely proceed.

Key Code Snippet from The Kernel Patch:

// x86/fred/ibt.c: ibt_clear_fred_wfe()

void ibt_clear_fred_wfe(struct pt_regs *regs)
{
    /* Clear WFE state before resuming execution */
    regs->cs_flags &= ~X86_CS_WFE;
}

Where is it used?

Inside the #CP (Control-Protection) exception handler, the kernel now calls ibt_clear_fred_wfe() to ensure WFE is not set for resumed execution unless it's truly fatal.

The bug is most dangerous for systems that

- Run on newer Intel CPUs with CET/IBT support.

On a vulnerable system

1. Trigger a #CP Fault: The attacker generates an indirect branch to an address not marked with ENDBR (easy in self-compiled user code or via certain JIT exploits).

Resumed execution: CPU returns to user code; WFE is still set.

4. Another #CP triggers: Repeats forever—process never escapes kernel's #CP handler, may lock up resources or cause a (local) denial-of-service.

Proof-of-Concept Illustration

While writing such a PoC requires root or kernel-level privileges to test, here’s an illustrative pseudocode for educational purposes:

;; Compile and run on a vulnerable system, user-mode (for demonstration)
jmp *rax
; No ENDBR marker here! Causes #CP if IBT enabled

In real scenarios, exploiting this requires knowledge of kernel internals and appropriate system exposure, but even accidents in legitimate code could cause hard-to-debug hangs.

References

- CVE-2024-56761 at MITRE
- Linux Kernel Patch Commit: x86/fred: Clear WFE in missing-ENDBRANCH #CPs
- Intel® 64 and IA-32 Architectures Software Developer’s Manual, Vol. 3, Section 7.9.28 (see IBT details)

This issue mostly affects bleeding-edge hardware and configurations (*IBT + FRED care!*)

- If you run a Linux server on new Intel chips using IBT/FRED, update your kernel promptly.

Always stay up to date with ongoing kernel security advisories!

Need more details or want to experiment safely? Join Kernelnewbies IRC or review upstream commits for more discussions about FRED, IBT, and how Linux tracks advanced hardware security features.

Timeline

Published on: 01/06/2025 17:15:41 UTC
Last modified on: 01/07/2025 23:05:19 UTC