SFOP: How Segmentation Fault Oriented Programming Bypasses Intel CET on Linux

This approach differs from traditional code‑reuse attacks like return‑oriented programming (ROP), which rely on manipulating return addresses. SFOP instead relies on repeated fault‑handling events to move execution forward.

Why Intel CET Was Supposed to Stop This

Intel introduced Control‑Flow Enforcement Technology (CET) as a hardware defense against code‑reuse attacks. CET combines several mechanisms, including protections that validate return addresses and restrict indirect branch targets.

The goal is to prevent attackers from hijacking program control flow by jumping to unintended instructions within existing code.

However, CET primarily protects against illegitimate control‑flow transfers inside a program’s normal execution paths.

SFOP bypasses this by using legitimate operating‑system behavior instead.

How SFOP Bypasses CET on Linux

The key insight behind SFOP is that signal delivery itself is a valid control‑flow transition managed by the operating system.

The attack works roughly as follows:

1. The exploit causes the victim program to access restricted memory, triggering a segmentation fault.
2. Linux raises a SIGSEGV signal and transfers execution to the registered signal handler.
3. The handler performs a controlled action—often preparing another fault condition.
4. The program crashes again, causing the next signal delivery.

Each signal handler effectively becomes a link in a chain of attacker‑controlled execution steps. Because the transition into the handler is an OS‑approved control transfer, it can bypass the protections CET normally enforces for indirect branches and returns.

Through repeated crashes and handler executions, attackers can stitch together behavior that ultimately enables arbitrary code execution using existing program components.

The Role of Linux SIGSEGV Signal Handling

Linux programs can register handlers for signals like SIGSEGV. These handlers allow software to respond to crashes—for example by logging the error or attempting recovery.

SFOP exploits this mechanism by:

• repeatedly triggering segmentation faults
• invoking the handler each time
• changing the executed code at each step

Each crash becomes part of a deliberate sequence that advances the exploit state until the attacker achieves the desired outcome.

This makes the signal‑handling mechanism itself a reusable control‑flow building block.

Proposed Mitigations

Researchers and security engineers have proposed several defensive strategies to reduce the risk from SFOP‑style attacks.

Linux Kernel Hardening

One mitigation path involves changes to Linux’s signal‑handling behavior to reduce how attackers can repeatedly exploit segmentation faults and signal handlers as control‑flow primitives. Public summaries of the research mention kernel‑level patches, though detailed implementation information remains limited in currently available reports.

PLaTypus Hardening Layer

Another proposed defense is PLaTypus, a research hardening mechanism designed to strengthen CET against modern code‑reuse techniques.

PLaTypus focuses on limiting control‑flow transitions between different libraries in a program. Researchers observed that attackers can still redirect execution across shared libraries even when CET protections are active.

The hardening layer restricts indirect jumps so that transitions typically remain within the same library unless explicitly permitted, significantly reducing the number of useful code‑reuse targets available to attackers.

Why SFOP Matters

The SFOP research highlights an important lesson in modern security architecture: hardware defenses alone are not enough if operating‑system behavior can still provide exploitable control‑flow primitives.

Even sophisticated protections like Intel CET can be undermined when attackers find ways to route execution through legitimate system mechanisms such as signal handling.

As hardware protections become standard across operating systems, research like this helps identify subtle gaps and guide the next generation of mitigations.

For security engineers and system developers, the key takeaway is clear: defenses must consider the entire stack—from CPU features to OS internals—because attackers will exploit whichever layer still exposes a usable path.