Re: [PATCH 6.16.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] The IBPB flush for BPF JIT memory reuse is bypassed for allocations larger than `BPF_PROG_PACK_SIZE`, allowing unprivileged-to-privileged BTB poisoning (JIT spraying) when memory is reused.
- [High] System-wide IPI storm allowing Denial of Service via frequent BPF program loads.
--

--- Patch [2]: [PATCH 6.16.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation ---
commit 952665895a964d3f1620c223a7c5e6f20ea4be8a
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 65e253ef52184..512d58d6040c7 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -2234,6 +2247,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]
Could this implementation cause a system-wide IPI storm allowing a denial of
service via frequent BPF program loads?

When bpf_prog_pack_alloc() in kernel/bpf/core.c allocates a chunk, it
synchronously calls bpf_arch_pred_flush() which maps here. This issues
on_each_cpu(), sending inter-processor interrupts to all online CPU cores and
blocking until they complete write_ibpb().

Because an unprivileged user can loop creating cBPF programs via
setsockopt(..., SO_ATTACH_FILTER, ...) and this allocation has no rate
limiting, won't this trivially cause an IPI storm?

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

[ ... ]

> @@ -2310,6 +2344,14 @@ static void __init spectre_v2_apply_mitigation(void)
>  		setup_force_cpu_cap(X86_FEATURE_USE_IBRS_FW);
>  		pr_info("Enabling Restricted Speculation for firmware calls\n");
>  	}
> +
> +#ifdef CONFIG_BPF_JIT
> +	if (cpu_wants_ibpb_bpf()) {
> +		static_call_update(bpf_arch_pred_flush, bpf_arch_ibpb);
> +		static_branch_enable(&bpf_pred_flush_enabled);

[Severity: High]
Does this allow a bypass of the JIT spraying mitigation for allocations
larger than BPF_PROG_PACK_SIZE?

In kernel/bpf/core.c, bpf_prog_pack_alloc() bypasses the predictor flush
for large allocations:

	if (size > BPF_PROG_PACK_SIZE) {
		/* ... */
		if (static_branch_unlikely(&bpf_pred_flush_enabled))
			pr_warn_once("...");
		size = round_up(size, PAGE_SIZE);
		ptr = bpf_jit_alloc_exec(size);
		goto out;
	}

Could an unprivileged attacker load many small cBPF programs to fill a
BPF_PROG_PACK_SIZE block, poison the branch predictor, and then unload them
to return the block to the execmem allocator?

If a privileged user then loads a large BPF program, couldn't the victim's
program be loaded into this exact poisoned address space without a flush,
allowing the attacker to hijack control flow?

> +		pr_info("Enabling IBPB for BPF\n");
> +	}
> +#endif
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-cbpf-jit-spray-hardening-6-16-y-v1-0-2fc3e16263ac@linux.intel.com?part=2