{
	"id": "fcea4d49-1502-4fe6-8da0-685a1252f0c6",
	"created_at": "2026-04-06T01:30:59.202966Z",
	"updated_at": "2026-04-10T03:26:53.357712Z",
	"deleted_at": null,
	"sha1_hash": "1f5bcec8445e30016bc2231fa49a638732a50a4c",
	"title": "Control-flow integrity",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 144555,
	"plain_text": "Control-flow integrity\r\nBy Contributors to Wikimedia projects\r\nPublished: 2016-06-01 · Archived: 2026-04-06 01:10:16 UTC\r\nFrom Wikipedia, the free encyclopedia\r\nNot to be confused with Common Flash Interface, the flash memory device identification standard.\r\nControl-flow integrity (CFI) is a general term for computer security techniques that prevent a wide variety of\r\nmalware attacks from redirecting the flow of execution (the control flow) of a program.\r\nA computer program commonly changes its control flow to make decisions and use different parts of the code.\r\nSuch transfers may be direct, in that the target address is written in the code itself, or indirect, in that the target\r\naddress itself is a variable in memory or a CPU register. In a typical function call, the program performs a direct\r\ncall, but returns to the caller function using the stack – an indirect backward-edge transfer. When a function\r\npointer is called, such as from a virtual table, we say there is an indirect forward-edge transfer.\r\n[1][2]\r\nAttackers seek to inject code into a program to make use of its privileges or to extract data from its memory space.\r\nBefore executable code was commonly made read-only, an attacker could arbitrarily change the code as it is run,\r\ntargeting direct transfers or even do with no transfers at all. After W^X became widespread, an attacker wants to\r\ninstead redirect execution to a separate, unprotected area containing the code to be run, making use of indirect\r\ntransfers: one could overwrite the virtual table for a forward-edge attack or change the call stack for a backward-edge attack (return-oriented programming). CFI is designed to protect indirect transfers from going to unintended\r\nlocations.[1]\r\nAssociated techniques include code-pointer separation (CPS), code-pointer integrity (CPI), stack canaries, shadow\r\nstacks (SS), and vtable pointer verification.[3][4][5] These protections can be classified into either coarse-grained\r\nor fine-grained based on the number of targets restricted. A coarse-grained forward-edge CFI implementation,\r\ncould, for example, restrict the set of indirect call targets to any function that may be indirectly called in the\r\nprogram, while a fine-grained one would restrict each indirect call site to functions that have the same type as the\r\nfunction to be called. Similarly, for a backward edge scheme protecting returns, a coarse-grained implementation\r\nwould only allow the procedure to return to a function of the same type (of which there could be many, especially\r\nfor common prototypes), while a fine-grained one would enforce precise return matching (so it can return only to\r\nthe function that called it).\r\nRelated implementations are available in Clang (LLVM front-end),[6], GNU Compiler Collection[7], Microsoft's\r\nControl Flow Guard[8][9][10] and Return Flow Guard,[11] Google's Indirect Function-Call Checks[12] and Reuse\r\nAttack Protector (RAP).[13][14]\r\nThe LLVM compiler's C/C++ front-end Clang provides a number of \"CFI\" schemes that works on the forward\r\nedge by checking for errors in virtual tables and type casts. Not all of the schemes are supported on all platforms\r\nhttps://en.wikipedia.org/wiki/Control-flow_integrity\r\nPage 1 of 5\n\nand most of them, the exception being two \"kcfi\" schemes intended for low-level kernel software, depends on\r\nlink-time optimization (LTO) to know what functions are supposed to be called in normal cases.[15]\r\nAlso provided is a separate \"shadow call stack\" (SCS) instrumentation pass that defends on the backward edge by\r\nchecking for call stack modifications, available only for the aarch64 and RISC-V ISAs. And due to use of a shared\r\nprocessor register SCS is only enforceable on certain ABIs or if in other ways it is ensured that any other software\r\nusing the register set (thread/processor) does not interfere with this use.[16]\r\nGoogle has shipped Android with the Linux kernel compiled by Clang with link-time optimization (LTO) and CFI\r\nenabled since 2018.[17] Even though SCS is available for the Linux kernel as an option, and support is also\r\navailable for Android's system components it is recommended only to enable it for components for which it can be\r\nensured that no third party code is loaded.[18]\r\nThe GNU Compiler Collection implemented a \"shadow call stack\" compatible with Clang for aarch64 in v12\r\nreleased in 2022.[19][20] This feature is primarily intended for building the Linux kernel as support is missing from\r\nGCC user space libraries.[7]\r\nIntel Control-flow Enforcement Technology\r\n[edit]\r\nIntel Control-flow Enforcement Technology (CET) detects compromises to control flow integrity with a shadow\r\nstack (SS) and indirect branch tracking (IBT).[21][22]\r\nThe kernel must map a region of memory for the shadow stack not writable to user space programs except by\r\nspecial instructions. The shadow stack stores a copy of the return address of each CALL. On a RET, the processor\r\nchecks if the return address stored in the normal stack and shadow stack are equal. If the addresses are not equal,\r\nthe processor generates an INT #21 (Control Flow Protection Fault).\r\nIndirect branch tracking detects indirect JMP or CALL instructions to unauthorized targets. It is implemented by\r\nadding a new internal state machine in the processor. The behavior of indirect JMP and CALL instructions is\r\nchanged so that they switch the state machine from IDLE to WAIT_FOR_ENDBRANCH. In the\r\nWAIT_FOR_ENDBRANCH state, the next instruction to be executed is required to be the new ENDBRANCH\r\ninstruction (ENDBR32 in 32-bit mode or ENDBR64 in 64-bit mode), which changes the internal state machine\r\nfrom WAIT_FOR_ENDBRANCH back to IDLE. Thus every authorized target of an indirect JMP or CALL must\r\nbegin with ENDBRANCH. If the processor is in a WAIT_FOR_ENDBRANCH state (meaning, the previous\r\ninstruction was an indirect JMP or CALL), and the next instruction is not an ENDBRANCH instruction, the\r\nprocessor generates an INT #21 (Control Flow Protection Fault). On processors not supporting CET indirect\r\nbranch tracking, ENDBRANCH instructions are interpreted as NOPs and have no effect.\r\nMicrosoft Control Flow Guard\r\n[edit]\r\nhttps://en.wikipedia.org/wiki/Control-flow_integrity\r\nPage 2 of 5\n\nControl Flow Guard (CFG) was first released for Windows 8.1 Update 3 (KB3000850) in November 2014.\r\nDevelopers can add CFG to their programs by adding the /guard:cf linker flag before program linking in Visual\r\nStudio 2015 or newer.\r\n[23]\r\nAs of Windows 10 Creators Update (Windows 10 version 1703), the Windows kernel is compiled with CFG.[24]\r\nThe Windows kernel uses Hyper-V to prevent malicious kernel code from overwriting the CFG bitmap.[25]\r\nCFG operates by creating a per-process bitmap, where a set bit indicates that the address is a valid destination.\r\nBefore performing each indirect function call, the application checks if the destination address is in the bitmap. If\r\nthe destination address is not in the bitmap, the program terminates.[23] This makes it more difficult for an attacker\r\nto exploit a use-after-free by replacing an object's contents and then using an indirect function call to execute a\r\npayload.[26]\r\nImplementation details\r\n[edit]\r\nFor all protected indirect function calls, the _guard_check_icall function is called, which performs the\r\nfollowing steps:[27]\r\n1. Convert the target address to an offset and bit number in the bitmap.\r\n1. The highest 3 bytes are the byte offset in the bitmap\r\n2. The bit offset is a 5-bit value. The first four bits are the 4th through 8th low-order bits of the\r\naddress.\r\n3. The 5th bit of the bit offset is set to 0 if the destination address is aligned with 0x10 (last four bits\r\nare 0), and 1 if it is not.\r\n2. Examine the target's address value in the bitmap\r\n1. If the target address is in the bitmap, return without an error.\r\n2. If the target address is not in the bitmap, terminate the program.\r\nThere are several generic techniques for bypassing CFG:\r\nSet the destination to code located in a non-CFG module loaded in the same process.[26][28]\r\nFind an indirect call that was not protected by CFG (either CALL or JMP).[26][28][29]\r\nUse a function call with a different number of arguments than the call is designed for, causing a stack\r\nmisalignment, and code execution after the function returns (patched in Windows 10).[30]\r\nUse a function call with the same number of arguments, but one of pointers passed is treated as an object\r\nand writes to a pointer-based offset, allowing overwriting a return address.[31]\r\nOverwrite the function call used by the CFG to validate the address (patched in March 2015)[29]\r\nSet the CFG bitmap to all 1's, allowing all indirect function calls[29]\r\nUse a controlled-write primitive to overwrite an address on the stack (since the stack is not protected by\r\nCFG) [29]\r\nhttps://en.wikipedia.org/wiki/Control-flow_integrity\r\nPage 3 of 5\n\nMicrosoft eXtended Flow Guard\r\n[edit]\r\neXtended Flow Guard (XFG) has not been officially released yet, but is available in the Windows Insider preview\r\nand was publicly presented at Bluehat Shanghai in 2019.[32]\r\nXFG extends CFG by validating function call signatures to ensure that indirect function calls are only to the\r\nsubset of functions with the same signature. Function call signature validation is implemented by adding\r\ninstructions to store the target function's hash in register r10 immediately prior to the indirect call and storing the\r\ncalculated function hash in the memory immediately preceding the target address's code. When the indirect call is\r\nmade, the XFG validation function compares the value in r10 to the target function's stored hash. [33][34]\r\nBuffer overflow protection\r\n1. ^ Jump up to: a\r\n \r\nb\r\n Payer, Mathias. \"Control-Flow Integrity: An Introduction\". nebelwelt.net.\r\n2. ^ Burow, Nathan; Carr, Scott A.; Nash, Joseph; Larsen, Per; Franz, Michael; Brunthaler, Stefan; Payer,\r\nMathias (31 January 2018). \"Control-Flow Integrity: Precision, Security, and Performance\". ACM\r\nComputing Surveys. 50 (1): 1–33. doi:10.1145/3054924.\r\n3. ^ Payer, Mathias; Kuznetsov, Volodymyr. \"On differences between the CFI, CPS, and CPI properties\".\r\nnebelwelt.net. Retrieved 2016-06-01.\r\n4. ^ \"Adobe Flash Bug Discovery Leads To New Attack Mitigation Method\". Dark Reading. 10 November\r\n2015. Retrieved 2016-06-01.\r\n5. ^ Endgame. \"Endgame to Present at Black Hat USA 2016\". www.prnewswire.com (Press release).\r\nRetrieved 2016-06-01.\r\n6. ^ \"Control Flow Integrity — Clang 3.9 documentation\". clang.llvm.org. Retrieved 2016-06-01.\r\n7. ^ Jump up to: a\r\n \r\nb\r\n \"GCC Manual - Program Instrumentation Options\". GCC Project. Retrieved 19 March\r\n2026.\r\n8. ^ Pauli, Darren. \"Microsoft's malware mitigator refreshed, but even Redmond says it's no longer needed\".\r\nThe Register. Retrieved 2016-06-01.\r\n9. ^ Mimoso, Michael (2015-09-22). \"Bypass Developed for Microsoft Memory Protection, Control Flow\r\nGuard\". Threatpost | The first stop for security news. Retrieved 2016-06-01.\r\n10. ^ Smith, Ms. (23 September 2015). \"DerbyCon: Former BlueHat prize winner will bypass Control Flow\r\nGuard in Windows 10\". Network World. Archived from the original on September 27, 2015. Retrieved\r\n2016-06-01.\r\n11. ^ \"Return Flow Guard\". Tencent. 2 November 2016. Retrieved 2017-01-19.\r\n12. ^ Tice, Caroline; Roeder, Tom; Collingbourne, Peter; Checkoway, Stephen; Erlingsson, Úlfar; Lozano,\r\nLuis; Pike, Geoff (2014-01-01). Enforcing Forward-Edge Control-Flow Integrity in GCC \u0026 LLVM.\r\npp. 941–955. ISBN 9781931971157.\r\n13. ^ Security, heise (4 May 2016). \"PaX Team stellt Schutz vor Code Reuse Exploits vor\". Security (in\r\nGerman). Retrieved 2016-06-01.\r\n14. ^ \"Frequently Asked Questions About RAP\". Retrieved 2016-06-01.\r\n15. ^ \"Control Flow Integrity — Clang 23.0.0git documentation\". clang.llvm.org. Retrieved 19 March 2026.\r\nhttps://en.wikipedia.org/wiki/Control-flow_integrity\r\nPage 4 of 5\n\n16. ^ \"ShadowCallStack — Clang 23.0.0git documentation\". clang.llvm.org. Retrieved 19 March 2026.\r\n17. ^ \"Clang LTO Patches Updated for the Linux Kernel - Phoronix\".\r\n18. ^ \"ShadowCallStack\". Android Open Source Project.\r\n19. ^ \"GCC 12 Release Series - General Improvements\". GCC Project. Retrieved 19 March 2026.\r\n20. ^ \"GCC 12 Release Series - Release History\". GCC Project. Retrieved 19 March 2026.\r\n21. ^ \"Control-flow Enforcement Technology Specification\" (PDF). Intel Developer Zone. Archived from the\r\noriginal (PDF) on 2017-08-14. Retrieved 2021-01-05.\r\n22. ^ \"R.I.P ROP: CET Internals in Windows 20H1\". Winsider Seminars \u0026 Solutions Inc. 5 January 2020.\r\nRetrieved 2021-01-05.\r\n23. ^ Jump up to: a\r\n \r\nb\r\n \"Control Flow Guard\". MSDN. Retrieved 2017-01-19.\r\n24. ^ \"Analysis of the Shadow Brokers release and mitigation with Windows 10 virtualization-based security\".\r\nMicrosoft Technet. 16 June 2017. Retrieved 2017-06-20.\r\n25. ^ \"Universally Bypassing CFG Through Mutability Abuse\" (PDF). Alex Ionescu's Blog. Retrieved 2017-\r\n07-07.\r\n26. ^ Jump up to: a\r\n \r\nb\r\n \r\nc\r\n Falcón, Francisco (2015-03-25). \"Exploiting CVE-2015-0311, Part II: Bypassing\r\nControl Flow Guard on Windows 8.1 Update 3\". Core Security. Retrieved 2017-01-19.\r\n27. ^ \"Control Flow Guard\" (PDF). Trend Micro. Retrieved 2017-01-19.\r\n28. ^ Jump up to: a\r\n \r\nb\r\n \"Windows 10 Control Flow Guard Internals\" (PDF). Power of Community. Retrieved\r\n2017-01-19.\r\n29. ^ Jump up to: a\r\n \r\nb\r\n \r\nc\r\n \r\nd\r\n \"Bypass Control Flow Guard Comprehensively\" (PDF). BlackHat. Retrieved 2017-01-\r\n19.\r\n30. ^ \"An interesting detail about Control Flow Guard\". Bromium. Retrieved 2017-01-19.\r\n31. ^ Thomas, Sam (18 August 2016). \"Object Oriented Exploitation: New techniques in Windows mitigation\r\nbypass\". Slideshare. Retrieved 2017-01-19.\r\n32. ^ \"Advancing Windows Security\". Retrieved 2021-05-19.\r\n33. ^ \"EXTENDED FLOW GUARD UNDER THE MICROSCOPE\". 18 May 2021. Retrieved 2021-05-19.\r\n34. ^ \"Exploit Development: Between a Rock and a (Xtended Flow) Guard Place: Examining XFG\". 23 August\r\n2020. Retrieved 2021-05-19.\r\nSource: https://en.wikipedia.org/wiki/Control-flow_integrity\r\nhttps://en.wikipedia.org/wiki/Control-flow_integrity\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://en.wikipedia.org/wiki/Control-flow_integrity"
	],
	"report_names": [
		"Control-flow_integrity"
	],
	"threat_actors": [
		{
			"id": "d4f7cf97-9c98-409c-8b95-b80d14c576a5",
			"created_at": "2022-10-25T16:07:24.561104Z",
			"updated_at": "2026-04-10T02:00:05.03343Z",
			"deleted_at": null,
			"main_name": "Shadow Brokers",
			"aliases": [],
			"source_name": "ETDA:Shadow Brokers",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "171b85f2-8f6f-46c0-92e0-c591f61ea167",
			"created_at": "2023-01-06T13:46:38.830188Z",
			"updated_at": "2026-04-10T02:00:03.114926Z",
			"deleted_at": null,
			"main_name": "The Shadow Brokers",
			"aliases": [
				"Shadow Brokers",
				"ShadowBrokers",
				"The ShadowBrokers",
				"TSB"
			],
			"source_name": "MISPGALAXY:The Shadow Brokers",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775439059,
	"ts_updated_at": 1775791613,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1f5bcec8445e30016bc2231fa49a638732a50a4c.pdf",
		"text": "https://archive.orkl.eu/1f5bcec8445e30016bc2231fa49a638732a50a4c.txt",
		"img": "https://archive.orkl.eu/1f5bcec8445e30016bc2231fa49a638732a50a4c.jpg"
	}
}