Control-Flow Integrity

Control-flow integrity (CFI) is a security mechanism that prevents software attacks from redirecting the execution flow of a program to arbitrary locations. In a typical exploit, an attacker overwrites a function pointer or return address — through a buffer overflow or use-after-free vulnerability — to jump to malicious code. CFI mitigates this by restricting the set of valid control-flow targets to those that appear in the program's legitimate control-flow graph.

The mechanism is implemented by instrumenting the program to verify, before every indirect jump or call, that the target is among the allowed destinations. Early CFI schemes used coarse-grained checks — permitting jumps to any function entry point, for example — which were efficient but left many exploitable targets. Modern implementations, such as Microsoft's Control Flow Guard and LLVM's clang CFI, use fine-grained policies that distinguish between different types of control transfers, reducing the attack surface at the cost of performance overhead and binary size.

CFI is not a complete solution. It does not prevent data-only attacks, where corrupted data values alter program behavior without changing control flow. It also struggles with just-in-time compilation and self-modifying code, where the control-flow graph is not static and cannot be determined ahead of time. The tension between security and flexibility is acute: CFI assumes the program is a fixed artifact, but modern software is increasingly dynamic.

CFI is a Band-Aid on a structural wound. The wound is that programming languages permit memory corruption; the Band-Aid is a runtime check that says, in effect, 'if you are going to be corrupted, at least be corrupted in a way we predicted.' The correct fix is not finer-grained CFI but languages that make CFI unnecessary. The fact that we are still building CFI systems in 2026 is an indictment of the software industry's willingness to prioritize performance over safety.