Re: [PATCH bpf 2/6] bpf: Bound the number of indirect jump edges in a program

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Integer overflow in jump table size calculation leads to massive out-of-bounds memory access.
--

commit 4185a35dbc8e33f3114fd8855cb5ca01b0ecf5a9
Author: Daniel Borkmann <daniel@iogearbox.net>

bpf: Bound the number of indirect jump edges in a program

Bounds the total number of gotox edges across the program at
BPF_COMPLEXITY_LIMIT_INSNS to prevent excessive memory and CPU usage
during program loading.

Reported-by: STAR Labs SG <info@starlabs.sg>

[ ... ]

> diff --git a/kernel/bpf/cfg.c b/kernel/bpf/cfg.c
> index 081f7003eae66..e9910228da587 100644
> --- a/kernel/bpf/cfg.c
> +++ b/kernel/bpf/cfg.c
> @@ -388,6 +390,19 @@ static int visit_gotox_insn(int t, struct bpf_verifier_env *env)
>  			return PTR_ERR(jt);
>  
>  		env->insn_aux_data[t].jt = jt;
> +
> +		if (check_add_overflow(env->cfg.gotox_edges, jt->cnt,
> +				       &env->cfg.gotox_edges) ||
> +		    env->cfg.gotox_edges > BPF_MAX_GOTOX_EDGES) {
> +			verbose(env, "number of indirect jump edges in the program exceeds %u\n",
> +				BPF_MAX_GOTOX_EDGES);
> +			bpf_diag_program_structure(
> +				env, t, "too many indirect jump edges",
> +				"Reduce the number of indirect jumps, or the number of distinct targets they can reach.",
> +				"The program has more than %u indirect jump edges in total, counted over every gotox instruction.",
> +				BPF_MAX_GOTOX_EDGES);
> +			return -E2BIG;
> +		}

[Severity: Critical]
This isn't a bug introduced by this patch, but it is a pre-existing issue
in the CFG discovery logic that remains unfixed in this patch series.

Can jt_from_subprog() in kernel/bpf/cfg.c overflow the shift operation
when calculating the size for memcpy()?

If a user with CAP_BPF creates an INSN_ARRAY map with a very large
max_entries (e.g., 0x20000000) and populates it, jt_cur->cnt can be up to
map->max_entries.

In kernel/bpf/cfg.c:jt_from_subprog():

    memcpy(jt->items + old_cnt, jt_cur->items, jt_cur->cnt << 2);

If jt_cur->cnt reaches 0x20000000, the expression jt_cur->cnt << 2
evaluates as a signed 32-bit integer, resulting in -2147483648.

When passed to memcpy(), which expects a size_t, this negative value is
sign-extended to 0xFFFFFFFF80000000 on 64-bit systems. memcpy() attempts
to copy over 18 exabytes of data, causing a catastrophic page fault.

Additionally, if max_entries is 0x40000000, the shift results in 0,
leaving jt->items uninitialized before it is passed to
sort_insn_array_uniq().

>  	}
>  
>  	mark_prune_point(env, t);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909204035.24289-1-daniel@iogearbox.net?part=2