News › security
By The Linux Camp News, October 10, 2026
The proposed GCC support would check indirect kernel calls against function-type hashes. GCC 17 was the anticipated destination, but the supplied evidence does not establish a merge or released implementation.
LWN's February 6, 2026 report identified a compiler gap in Linux kernel hardening: -fsanitize=kcfi, the flag used by the kernel's newer control-flow integrity implementation, was available in Clang but not GCC. Control-flow integrity, or CFI, restricts where execution can go; the kernel's forward-edge protection focuses on indirect function calls, where a function pointer selects the destination. 1
Kees Cook's proposed GCC implementation covered x86_64, 32-bit and 64-bit Arm, and RISC-V. LWN reported that GCC developer Jeffrey Law considered the series ready for GCC 17 after the last GCC 16 release. That was an anticipated destination, not a released feature: the same report explicitly said support had not yet landed. 1
The proposed design follows Clang: the compiler calculates a hash, a compact identifier derived from a function's type, and stores it immediately before the function's implementation. Before an indirect call, generated code compares the destination's hash with the type expected by the caller. This makes the destination's type checkable at runtime rather than simply trusting the function pointer. 1
For operators, the security benefit has an availability consequence. LWN describes a type mismatch as causing a kernel panic, stopping execution rather than allowing the incompatible call to proceed. This is a mitigation, not comprehensive protection against redirected calls: an attacker can still choose another function with a matching signature. The check narrows the possible destinations without proving that the selected function is the one the programmer intended. 1
Compatibility matters particularly for kernels combining GCC-built C with Rust built by rustc, which uses LLVM for code generation. Cook wants CFI to work across that boundary. An indirect call from either language must calculate the same type identifier as the destination compiled by the other toolchain; otherwise, a legitimate call could fail the comparison. This is the interoperability goal described by LWN, not evidence of completed mixed-toolchain validation. 1
Kernel builders evaluating the proposal should check the configuration option and compiler feature detection together. Linux 6.18 renamed CONFIG_CFI_CLANG to CONFIG_CFI. LWN says feature detection should also let older stable kernels use the proposed GCC support despite retaining the Clang-specific name. The practical inference is that neither the option's spelling nor the kernel version alone establishes compiler compatibility; that older-stable claim remains prospective in this report. 1
The later evidence does not settle delivery status. The Kernel Self-Protection Project issue listing retrieved October 10, 2026 still labels GCC KCFI support as submitted. That tracker label is not a GCC merge record or release manifest, so it cannot establish whether the series subsequently landed or which compiler build first contains it. Deployment planning still needs that confirmation rather than treating the February GCC 17 expectation as an availability guarantee. 2