CVE-2026-97944: x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash()
In the Linux kernel, the following vulnerability has been resolved:
x86/cfi: Fix FineIBT hash offset in cfigetfunchash()
The switch of the FineIBT preamble from "subl $hash, %r10d" to the shorter "subl $hash, %eax" moved the hash immediate from offset 7 to offset 5 of the preamble. fineibtpreamblehash was updated to match, but the open-coded offset in cfigetfunchash() was missed and it still reads the hash at offset 7.
cfigetfunchash() is used by the BPF JIT to give a structops trampoline the CFI hash of the stub function it stands in for. With FineIBT the trampoline now gets the upper half of the real hash followed by the first two bytes of the next instruction, so the first indirect call from the kernel into a structops program, tcpinitcongestioncontrol() calling ->init() of a BPF congestion control for example, fails the FineIBT check and the kernel dies with a CFI failure.
Move the FineIBT preamble template and its offset defines above cfigetfunchash() and use fineibtpreamblehash there, so every reader of the preamble shares one definition of its layout. The CFIFINEIBT arm is only built with CONFIGFINEIBT, the only configuration in which cfimode can take that value. cfigetfuncarity() does not need the same treatment: the bhiargs call whose displacement it reads still ends at the function address.
Affected Software
Event History
Frequently Asked Questions
Which systems are affected in practice?
The failure is limited to x86 kernels built with CONFIG_FINEIBT and using BPF struct_ops trampolines. An example given is a BPF TCP congestion-control program whose init callback is invoked by tcp_init_congestion_control().
What triggers the failure?
The first indirect call from the kernel into the affected struct_ops program triggers a FineIBT check using an incorrect CFI hash. That check fails and causes the kernel to terminate with a CFI failure.
How can I tell whether this issue is occurring?
A kernel death reporting a CFI failure when the kernel first indirectly calls a BPF struct_ops program is the stated symptom. This is associated with an incorrect hash being read for the trampoline stub under FineIBT.