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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bypass of Branch Target Injection (BTI) mitigation for large privileged BPF programs.
--

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

bpf: Support for hardening against JIT spraying

This commit introduces a mitigation against JIT spraying by flushing the 
indirect branch predictors before reusing JIT memory. It adds 
bpf_arch_pred_flush to flush predictors when allocating space from 
reused packs. For allocations larger than a pack, the flush is skipped.

> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 77044d4a80cc1..4643554c6e3a9 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
[ ... ]
> @@ -905,6 +915,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");
>  		size = round_up(size, PAGE_SIZE);
>  		ptr = module_alloc(size);
>  		if (ptr) {

[Severity: High]
Does skipping the flush here leave large privileged eBPF programs vulnerable
to Branch Target Injection (BTI) if they reuse memory previously occupied by
an attacker's smaller cBPF programs?

If an unprivileged attacker loads many small cBPF programs, they can cause
the allocator to allocate a new pack via module_alloc(). The attacker can
then train the CPU branch predictor at the virtual addresses within this pack.

When the attacker unloads the programs, the pack is emptied and returned to
the vmalloc pool.

If a privileged user then loads a large eBPF program (> BPF_PROG_PACK_SIZE),
bpf_prog_pack_alloc() will call module_alloc() directly. The vmalloc
allocator could return the exact same virtual address range previously
poisoned by the attacker.

Because the new allocation size is > BPF_PROG_PACK_SIZE, this code skips
calling bpf_arch_pred_flush(). Does this mean the safety of skipping the
flush depends on the size of the *new* program rather than the size of the
*old* program that previously occupied the memory?

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