Re: [PATCH 6.12.y 1/6] bpf: Support for hardening against JIT spraying

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Bypass of JIT spraying mitigation for large BPF allocations and trampolines due to shared virtual address pools.
- [High] Local-only branch predictor flush fails to protect against cross-CPU Spectre v2 attacks on SMP systems.
--

--- Patch [1]: [PATCH 6.12.y 1/6] bpf: Support for hardening against JIT spraying ---
commit e0ddacc731d8368cbba4bdc358a8403f702c92da
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>

bpf: Support for hardening against JIT spraying

This commit introduces a branch predictor flush mechanism before reusing
JIT memory to mitigate indirect jump prediction poisoning. It adds a static
call for architectures to define their flush routine and skips flushing
for allocations larger than a single pack size.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c

[ ... ]

> @@ -951,6 +961,14 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
>  
>  	mutex_lock(&pack_mutex);
>  	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.
> +		 */
> +		if (static_branch_unlikely(&bpf_pred_flush_enabled))
> +			pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");

[Severity: High]
Does skipping the flush for allocations larger than a pack leave them
vulnerable to poisoning?

Since all BPF allocations and trampolines share the same global virtual
address pool, could an attacker load a small unprivileged program to poison
the branch predictors for that virtual address, and then free it?

Once the empty pack is freed and its virtual addresses return to the
global pool, it seems a large privileged BPF program or trampoline could
be allocated that exact same virtual address range. Because large allocations
explicitly skip the flush here, would the privileged program end up executing
using the attacker's poisoned branch targets?

>  		size = round_up(size, PAGE_SIZE);
>  		ptr = bpf_jit_alloc_exec(size);
>  		if (ptr) {

[ ... ]

> @@ -981,6 +999,7 @@ 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)();

[Severity: High]
Is a local-only flush sufficient to protect against cross-CPU attacks on
SMP systems?

Branch target buffers are typically per-CPU. If an attacker executes a
program and poisons the predictors on CPU B, and a new privileged program
is subsequently allocated and flushes on CPU A, it appears CPU B's
predictors would remain poisoned.

If the victim program later executes on CPU B, for instance via a network
packet in softirq context, could it reuse the poisoned predictions left
behind by the attacker?

>  	bitmap_set(pack->bitmap, pos, nbits);
>  	ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
>

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