Re: [PATCH] x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash()

[Alexei Starovoitov]

On Tue, Sep 8, 2026 at 6:22 AM Soheil Hassas Yeganeh
<soheil.kdev@xxxxxxxxx> wrote:
>
> On Mon, Aug 31, 2026 at 10:49 AM Soheil Hassas Yeganeh
> <soheil.kdev@xxxxxxxxx> wrote:
> >
> > 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. fineibt_preamble_hash was updated to match,
> > but the open-coded offset in cfi_get_func_hash() was missed and it
> > still reads the hash at offset 7.
> >
> > cfi_get_func_hash() is used by the BPF JIT to give a struct_ops
> > 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 struct_ops program,
> > tcp_init_congestion_control() 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
> > cfi_get_func_hash() and use fineibt_preamble_hash there, so every
> > reader of the preamble shares one definition of its layout. The
> > CFI_FINEIBT arm is only built with CONFIG_FINEIBT, the only
> > configuration in which cfi_mode can take that value.
> > cfi_get_func_arity() does not need the same treatment: the __bhi_args
> > call whose displacement it reads still ends at the function address.
> >
> > Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA")
>
> Gentle ping on this one. To recap: since 85a2d4a890dc the FineIBT preamble
> stores the hash at +5, but cfi_get_func_hash() still reads it at +7, so BPF
> struct_ops trampolines are emitted with a wrong hash and the first indirect call
> through them (e.g. a bpf tcp_congestion_ops .cong_control) hits a FineIBT #CP.
>
> We have large scale panics when we use BPF congestion control.
> Happy to respin if a different shape is preferred (e.g. moving the
> offset next to
> the preamble definition), but this seemed like the best way to fix the issue.

Looks fine to me. I guess it will go via tip tree?