Control-Flow Integrity

A program's source code is full of indirect jumps: function pointers, virtual-method dispatch tables, and the humble return instruction. At compile time these jumps have obvious, intended targets. At run time an attacker who controls a corrupted pointer can send the jump anywhere in memory — including into the middle of a sequence of existing instructions that, chained together, do something malicious. No new shellcode needed.

This class of attack — return-oriented programming (ROP) and its cousins — became the dominant exploitation technique after hardware and OS defenses made injecting new executable code expensive. The attacker's payload is assembled entirely from gadgets: short instruction sequences already present in the binary, each ending with a ret or indirect jmp.

Control-Flow Integrity (CFI) answers with a simple invariant: every indirect branch must land on a target that the original program could legitimately reach. The compiler computes a set of valid targets for each call site and inserts a lightweight check before each indirect jump. If the redirected target is not in the approved set, the process is terminated before the gadget chain can do any damage.

The idea was formalized by Abadi, Budiu, Erlingsson and Ligatti in their landmark 2005 paper. Since then, LLVM, GCC, Microsoft's Control Flow Guard, and ARM's Branch Target Identification have turned CFI from a research curiosity into a production-grade defense deployed on billions of devices.

The demo below simulates a program with three legitimate call targets (A, B, C) and one malicious gadget that the attacker would like to jump to. The CFI policy records which targets are valid for each call site.

<!-- {{c_html_comment}} -->
<div class="cfi-container">
  <div class="policy-panel">
    <h3 class="panel-title">{{label_policy}}</h3>
    <div class="policy-row">
      <span class="site-label">{{label_call_site}}</span>
      <span class="arrow">→</span>
      <span class="valid-targets">
        <span class="target allowed" id="tgt-A">A</span>
        <span class="target allowed" id="tgt-B">B</span>
        <span class="target allowed" id="tgt-C">C</span>
        <span class="target forbidden" id="tgt-gadget">{{label_gadget}}</span>
      </span>
    </div>
    <p class="policy-note">{{label_policy_note}}</p>
  </div>
  <div class="controls">
    <div class="ctrl-row">
      <label class="ctrl-label">{{label_dest_pick}}</label>
      <select id="target-select">
        <option value="A">{{opt_A}}</option>
        <option value="B">{{opt_B}}</option>
        <option value="C">{{opt_C}}</option>
        <option value="gadget">{{opt_gadget}}</option>
      </select>
    </div>
    <div class="btn-row">
      <button id="btn-legit" type="button">{{btn_legit}}</button>
      <button id="btn-hijack" type="button" class="danger">{{btn_hijack}}</button>
      <button id="btn-clear" type="button" class="ghost">{{btn_clear}}</button>
    </div>
  </div>
  <div class="log-panel">
    <h3 class="panel-title">{{label_log}}</h3>
    <ul id="log-list"></ul>
  </div>
</div>

/* {{c_css_root}} */
* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; padding: .5rem; }
.cfi-container { display: flex; flex-direction: column; gap: .8rem; }
.panel-title { margin: 0 0 .4rem; font-size: .9rem; font-weight: 700; color: #1d3557; text-transform: uppercase; letter-spacing: .04em; }
.policy-panel { background: #eef2f7; border: 1px solid #cdd9e3; border-radius: 10px; padding: .7rem 1rem; }
.policy-row { display: flex; align-items: center; gap: .5rem; flex-wrap: wrap; }
.site-label { font: 700 .85rem ui-monospace, monospace; background: #1d3557; color: #fff; border-radius: 6px; padding: .15rem .5rem; }
.arrow { font-size: 1.1rem; color: #555; }
.valid-targets { display: flex; gap: .4rem; flex-wrap: wrap; }
.target { font: 700 .85rem ui-monospace, monospace; border-radius: 6px; padding: .2rem .55rem; border: 2px solid transparent; }
.target.allowed { background: #d4edda; color: #155724; border-color: #c3e6cb; }
.target.forbidden { background: #f8d7da; color: #721c24; border-color: #f5c6cb; }
.target.active { outline: 3px solid #f0a500; outline-offset: 2px; }
.policy-note { margin: .5rem 0 0; font-size: .78rem; color: #555; }
/* {{c_css_controls}} */
.controls { background: #f8f9fa; border: 1px solid #dee2e6; border-radius: 10px; padding: .7rem 1rem; }
.ctrl-row { display: flex; align-items: center; gap: .6rem; margin-bottom: .6rem; flex-wrap: wrap; }
.ctrl-label { font-size: .85rem; font-weight: 600; }
select { font-size: .9rem; padding: .3rem .5rem; border-radius: 6px; border: 1px solid #adb5bd; }
.btn-row { display: flex; gap: .5rem; flex-wrap: wrap; }
button { font: 600 .85rem system-ui; padding: .4rem .85rem; border-radius: 8px; cursor: pointer; border: 1px solid #1d3557; background: #1d3557; color: #fff; }
button.danger { background: #c92f3c; border-color: #a02535; }
button.ghost { background: #fff; color: #1d3557; }
/* {{c_css_log}} */
.log-panel { background: #fff; border: 1px solid #dee2e6; border-radius: 10px; padding: .7rem 1rem; max-height: 200px; overflow-y: auto; }
#log-list { list-style: none; margin: 0; padding: 0; display: flex; flex-direction: column; gap: .3rem; }
.log-entry { font-size: .82rem; font-family: ui-monospace, monospace; padding: .25rem .5rem; border-radius: 6px; }
.log-entry.pass { background: #d4edda; color: #155724; }
.log-entry.block { background: #f8d7da; color: #721c24; }
.log-entry.info { background: #e2ecf7; color: #1d3557; }

// Code not found

Click Legitimate call to dispatch to a valid target — CFI's check passes instantly. Click Hijacked jump to simulate an attacker redirecting the pointer to the gadget — CFI catches the mismatch and terminates the call before the gadget runs. The log shows every check as it happens. Notice that CFI adds only a tiny comparison before each branch; the protection is almost free.

CFI sounds simple: "only jump to valid targets." The hard part is computing what valid means.

• Coarse-grained CFI groups all indirect call targets into one big set (any function entry point) and all ret targets into another (any return address). This is fast to implement and catches many attacks, but leaves room for sophisticated gadget chains that stay within the large allowed set.
• Fine-grained CFI gives each call site its own target set, ideally restricted to functions whose signature matches the call. This is far more precise, but requires whole-program analysis — and when libraries are involved, that analysis must cross binary boundaries.
• The decidability limit. Fully precise CFI would require knowing, for every indirect call at run time, exactly which functions could be called there — equivalent to solving the halting problem. In practice, compilers use type-based approximations: a call through a pointer of type void(*)(int) may only target functions with that signature.
• Shadow stacks handle ret separately: a parallel, hardware-protected stack stores return addresses; a mismatched return is caught even before the CFI type check.

ARM's Pointer Authentication (PAC) and Intel's CET (Control-flow Enforcement Technology) bring shadow stacks into hardware, making the check essentially free and the stack nearly impossible to corrupt from software. On the software side, LLVM's CFI has been used in production in Chrome, Android, and major OS kernels since around 2016.

CFI is no longer a research idea — it is the beating heart of modern exploit mitigation:

• Browsers: Chrome and Firefox use LLVM CFI and shadow stacks to contain renderer exploits before they can escape the sandbox. A hijacked virtual-method call that once meant full browser compromise now terminates harmlessly.
• Operating system kernels: Linux kCFI, Windows CFG, and macOS pointer authentication protect kernel indirect calls from privilege-escalation gadget chains.
• Embedded and automotive systems: ARM BTI (Branch Target Identification) and PAC are mandatory in automotive-grade chips, where a hijacked control flow could affect physical safety.
• Compilers and toolchains: LLVM, GCC, and MSVC all ship CFI passes. Enabling -fsanitize=cfi in a Clang build inserts checks for every virtual call and indirect function call.
• Hardware acceleration: Intel CET's Shadow Stack and Indirect Branch Tracking (IBT) enforce the CFI invariant entirely in microcode, with near-zero overhead.

Understand CFI and you understand why buffer overflows can no longer trivially turn into arbitrary code execution — the control-flow graph itself has become a security boundary.

Control-Flow Integrity is one of those rare defenses that attacks the mechanism of exploitation rather than any individual vulnerability. Attackers find a buffer overflow, a use-after-free, a format-string bug — but without the ability to redirect a ret or an indirect jmp, their gadget chain collapses at the first check.

The invariant is deceptively simple: land only where the compiler said you could. Enforcing it precisely requires whole-program analysis and hardware support, and the theory brushes up against undecidability. But even coarse CFI raises the cost of a working exploit dramatically, and hardware shadow stacks make the ret hijack — the bread and butter of ROP — almost impossible.

Decades of memory corruption bugs taught us that we cannot write perfect code. CFI teaches us something different: even imperfect code can be far harder to exploit when the control-flow graph itself becomes a security boundary.