Re: [PATCH bpf-next 07/17] bpf, x86: Add JIT support for callx

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] bpf: callx bypasses KCFI due to missing caller-side hash check
--

commit d4dfd1b46a3e02ea97924c833ac04239e01627f1
Author: Alexei Starovoitov <ast@kernel.org>
Subject: bpf, x86: Add JIT support for callx

This commit adds JIT support for BPF indirect calls via the register that
holds the address of the BPF subprog. It introduces the emit_indirect_call
helper to handle the translation using ITS or retpoline thunks.

> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
[ ... ]
> @@ -749,6 +749,46 @@ static void emit_indirect_jump(u8 **pprog, int bpf_reg, u8 *ip)
>  	*pprog = prog;
>  }
>  
> +static void __emit_indirect_call(u8 **pprog, int reg, bool ereg)
> +{
> +	u8 *prog = *pprog;
> +
> +	if (ereg)
> +		EMIT1(0x41);
> +
> +	EMIT2(0xFF, 0xD0 + reg);
> +
> +	*pprog = prog;
> +}
> +
> +/* call *bpf_reg */
> +static int emit_indirect_call(u8 **pprog, int bpf_reg, u8 *ip)
> +{
> +	u8 *prog = *pprog;
> +	int reg = reg2hex[bpf_reg];
> +	bool ereg = is_ereg(bpf_reg);
> +	int err = 0;
> +
> +	if (cpu_feature_enabled(X86_FEATURE_INDIRECT_THUNK_ITS)) {
> +		OPTIMIZER_HIDE_VAR(reg);
> +		err = emit_call(&prog, its_static_thunk(reg + 8*ereg), ip);
> +	} else if (cpu_feature_enabled(X86_FEATURE_RETPOLINE_LFENCE)) {
> +		EMIT_LFENCE();
> +		__emit_indirect_call(&prog, reg, ereg);
> +	} else if (cpu_feature_enabled(X86_FEATURE_RETPOLINE)) {
> +		OPTIMIZER_HIDE_VAR(reg);
> +		if (cpu_feature_enabled(X86_FEATURE_CALL_DEPTH))
> +			err = emit_call(&prog, &__x86_indirect_call_thunk_array[reg + 8*ereg], ip);
> +		else
> +			err = emit_call(&prog, &__x86_indirect_thunk_array[reg + 8*ereg], ip);
> +	} else {
> +		__emit_indirect_call(&prog, reg, ereg);

[Severity: High]
Does emit_indirect_call() emit raw indirect branches without KCFI hash
validation?

If KCFI is active, it seems __emit_indirect_call() emits a bare indirect
branch instruction without the preceding caller-side hash check.

If an attacker were able to overwrite a spilled subprogram pointer, could they
trigger this execution path to jump to an arbitrary kernel address and bypass
KCFI protections?

> +	}
> +
> +	*pprog = prog;
> +	return err;
> +}
> +
[ ... ]
> @@ -4414,6 +4472,16 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_verifier_env *env, struct bpf_pr
>  	return prog;
>  }
>  
> +bool bpf_jit_supports_callx(void)
> +{
> +	/*
> +	 * FineIBT poisons ENDBR at the entry of a JITed function and expects
> +	 * indirect callers to go through the CFI preamble instead.
> +	 * callx doesn't do that yet.
> +	 */
> +	return cfi_mode != CFI_FINEIBT;

[Severity: High]
Can bpf_jit_supports_callx() incorrectly allow indirect calls to be compiled
when KCFI is enabled?

The current logic blocks FineIBT but permits compilation when the CFI mode is
CFI_KCFI.

Since emit_indirect_call() does not currently emit caller-side hash checks,
allowing compilation under KCFI seems to introduce uninstrumented indirect
branches into kernel space.

> +}
> +
>  bool bpf_jit_supports_kfunc_call(void)
>  {
>  	return true;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922011323.1298619-1-alexei.starovoitov@gmail.com?part=7