Re: [PATCH 7.1.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incomplete Spectre v2 / BHI mitigation for BPF JIT spraying on CPUs with RRSBA.
- [High] Unprivileged local Denial of Service (DoS) via synchronous IPI broadcast storm.
--

--- Patch [2]: [PATCH 7.1.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation ---
commit 9b68eba3d351f7dea03fa0a56d5f7eb7c06e801c
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

x86/bugs: Enable IBPB flush on BPF JIT allocation

Enable hardening against JIT spraying when Spectre-v2 mitigations are in
use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip
enabling the IBPB flush if the BPF dispatcher is already using a retpoline
sequence.

> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 83f51cab0b1e3..d9af230c05125 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
[ ... ]
> @@ -2238,6 +2251,27 @@ static void __init spectre_v2_update_mitigation(void)
>  		pr_info("%s\n", spectre_v2_strings[spectre_v2_enabled]);
>  }
>  
> +#ifdef CONFIG_BPF_JIT
> +static void __bpf_arch_ibpb(void *unused)
> +{
> +	write_ibpb();
> +}
> +
> +void bpf_arch_ibpb(void)
> +{
> +	on_each_cpu(__bpf_arch_ibpb, NULL, 1);
> +}

[Severity: High]
Does this expose the system to a Denial of Service (DoS) attack from
unprivileged users?

Since this static call is invoked during BPF JIT allocations (e.g. via
bpf_arch_pred_flush() in bpf_prog_pack_alloc()), an unprivileged user can
repeatedly attach and detach classic BPF socket filters using
setsockopt(SO_ATTACH_FILTER).

This would trigger on_each_cpu(..., 1) repeatedly, overwhelming all online
CPUs with a synchronous IPI broadcast and waiting for them to complete the
expensive write_ibpb() operation.

> +
> +static bool __init cpu_wants_ibpb_bpf(void)
> +{
> +	/* A genuine retpoline already neutralizes ring0 indirect predictions */
> +	if (retpoline_seq_enabled())
> +		return false;

[Severity: High]
Is it safe to assume retpolines are a complete mitigation here without also
verifying that RRSBA is safely disabled?

In other mitigation paths like bhi_apply_mitigation() and spectre_bhi_state(),
the kernel checks rrsba_disabled along with retpoline_seq_enabled() because
an RSB underflow on CPUs with Restricted Return Stack Buffer Alternate (RRSBA)
behavior can cause RET instructions to fall back to the BTB (which could be
poisoned by an attacker).

If a system has RRSBA that cannot be disabled, skipping the IBPB flush here
could leave the BPF JIT spraying mitigation incomplete.

> +
> +	return boot_cpu_has(X86_FEATURE_IBPB);
> +}
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709-cbpf-jit-spray-hardening-7-1-y-v1-0-5ac5a2d6797f@linux.intel.com?part=2