Re: [PATCH 6.6.y 3/6] bpf: Restrict JIT predictor flush to cBPF

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Spectre v2 mitigation bypass in BPF JIT allocator due to restricted predictor flush.
--

--- Patch [3]: [PATCH 6.6.y 3/6] bpf: Restrict JIT predictor flush to cBPF ---
commit 8a65f5d94c81da9af1257fa2e8b48ff8c73c9963
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

bpf: Restrict JIT predictor flush to cBPF

This commit restricts the predictor flush on memory reuse for BPF JIT
allocations to only cBPF programs. It adds a was_classic parameter to
bpf_prog_pack_alloc to determine if the flush is necessary, assuming eBPF
allocations do not require the overhead of flushing predictors on reuse.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 0d8008711629c..509f1b9c2b2e2 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
[ ... ]
> @@ -951,7 +951,9 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
>  	pos = 0;
>  
>  found_free_area:
> -	static_call_cond(bpf_arch_pred_flush)();
> +	/* Flush only for cBPF as it may contain a crafted gadget */
> +	if (static_branch_unlikely(&bpf_pred_flush_enabled) && was_classic)
> +		static_call_cond(bpf_arch_pred_flush)();

[Severity: High]
Does skipping the flush for eBPF allocations leave the branch predictor
vulnerable if the memory was previously used by a cBPF program?

If an attacker loads a cBPF program, trains the CPU branch predictor to
target a specific offset, and then frees it, could a subsequent eBPF program
allocated in the same memory chunk skip the flush because was_classic is
false? This might allow an attacker to trigger a kernel indirect branch that
mispredicts into the newly loaded eBPF program at the trained offset.

Also, if kernel.unprivileged_bpf_disabled=0, couldn't an attacker directly
use unprivileged eBPF programs to bypass the flush completely, since their
type is not BPF_PROG_TYPE_UNSPEC?

>  	bitmap_set(pack->bitmap, pos, nbits);
>  	ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
[ ... ]
> diff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c
> index fa3e9225aedc0..b3f164e31c6bb 100644
> --- a/kernel/bpf/dispatcher.c
> +++ b/kernel/bpf/dispatcher.c
> @@ -145,7 +145,7 @@ void bpf_dispatcher_change_prog(struct bpf_dispatcher *d, struct bpf_prog *from,
>  
>  	mutex_lock(&d->mutex);
>  	if (!d->image) {
> -		d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero);
> +		d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);

[Severity: High]
Similarly, does explicitly passing false here for the dispatcher skip the
flush, leaving it vulnerable to unintentional gadget exploitation via
leftover branch predictions?

>  		if (!d->image)
>  			goto out;
>  		d->rw_image = bpf_jit_alloc_exec(PAGE_SIZE);

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