Re: [PATCH 6.12.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] Missing IBPB flush on BPF JIT allocations larger than BPF_PROG_PACK_SIZE allows unprivileged predictions to poison a privileged >2MB BPF program.
- [High] cpu_wants_ibpb_bpf() disables IBPB for BPF JIT when retpoline is used without verifying if RRSBA is safely disabled, leaving some CPUs vulnerable to JIT spraying.
--

--- Patch [2]: [PATCH 6.12.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation ---
commit 90d2e2d257bd12908af084fbafc06d88ea57e96b
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 939401b5d2ef0..12544fdcadd6a 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
[ ... ]
> @@ -1868,6 +1881,27 @@ static void __init bhi_select_mitigation(void)
>  	setup_force_cpu_cap(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT);
>  }
>  
> +#ifdef CONFIG_BPF_JIT
> +static void __bpf_arch_ibpb(void *unused)
> +{
> +	entry_ibpb();
> +}
> +
> +void bpf_arch_ibpb(void)
> +{
> +	on_each_cpu(__bpf_arch_ibpb, NULL, 1);
> +}
> +
> +static bool __init cpu_wants_ibpb_bpf(void)
> +{
> +	/* A genuine retpoline already neutralizes ring0 indirect predictions */
> +	if (retpoline_seq_enabled())
> +		return false;

[Severity: High]
Does this check need to verify if RRSBA is safely disabled before returning
false?

Unlike bhi_select_mitigation() and spectre_bhi_state() which check
rrsba_disabled, this function skips the IBPB flush based on
retpoline_seq_enabled() alone. On CPUs where Restricted Return Stack Buffer
Alternate (RRSBA) behavior cannot be disabled, wouldn't this allow RET
instructions to speculatively fall back to the BTB, leaving them vulnerable to
JIT spraying attacks?

> +
> +	return boot_cpu_has(X86_FEATURE_IBPB);
> +}
> +#endif
> +
>  static void __init spectre_v2_select_mitigation(void)
>  {
>  	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
[ ... ]
> @@ -2051,6 +2085,14 @@ static void __init spectre_v2_select_mitigation(void)
>  		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);
> +		pr_info("Enabling IBPB for BPF\n");
> +	}
> +#endif
> +

[Severity: High]
Does this mitigation bypass IBPB flushes for BPF allocations larger than
BPF_PROG_PACK_SIZE?

Looking at bpf_prog_pack_alloc() in kernel/bpf/core.c, allocations larger
than BPF_PROG_PACK_SIZE skip the predictor flush:

kernel/bpf/core.c:bpf_prog_pack_alloc() {
	if (size > BPF_PROG_PACK_SIZE) {
		/*
		 * Allocations larger than a pack get their own pages, and
		 * predictors are not flushed for such allocation. This is only
		 * safe because cBPF programs (the unprivileged attack surface)
		 * are bounded well below a pack size.
		 */
		...
		ptr = bpf_jit_alloc_exec(size);

However, when an unprivileged user fills a BPF pack and frees it, the
memory is returned to the global allocator:

kernel/bpf/core.c:bpf_prog_pack_free() {
	if (bitmap_find_next_zero_area(pack->bitmap, BPF_PROG_CHUNK_COUNT, 0,
				       BPF_PROG_CHUNK_COUNT, 0) == 0) {
		list_del(&pack->list);
		bpf_jit_free_exec(pack->ptr);
		kfree(pack);
	}

Could this returned memory be re-allocated by the >BPF_PROG_PACK_SIZE path?
If a privileged user then allocates a large BPF program (>2MB), it would
use this unprivileged attacker-poisoned memory without an IBPB flush,
potentially allowing a Spectre v2 exploit against the privileged program.

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