Re: [PATCH bpf] bpf: guard classic uprobes against private-stack corruption

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

New issues:
- [Low] The patch causes a `-Wdiscarded-qualifiers` compiler warning in `bpf_prog_run_array_uprobe` and mistakenly removes `const` from `bpf_prog_run_array`.

Pre-existing issues:
- [High] Missing recursion context protection in the uprobe-multi path leads to per-CPU private stack corruption.
--

--- Patch [1]: [PATCH bpf] bpf: guard classic uprobes against private-stack corruption ---
commit d583ad326b3c9bb2b3cfd745309987d581a65249
Author: Christian Simon <[email protected]>

bpf: guard classic uprobes against private-stack corruption

Eligible BPF programs use one private stack per program and CPU.
bpf_prog_run_array_uprobe() uses migrate_disable() to keep an
invocation on one CPU, but another task can still preempt it and run
the same program on that CPU. The second invocation then reuses and
can overwrite the first invocation's private stack.

> The analogous uprobe-multi path appears affected but is not addressed by
> this patch.

[Severity: High]
This is a pre-existing issue, but since the uprobe-multi path shares this
vulnerability, shouldn't it be addressed as well to prevent private-stack
corruption?

In kernel/trace/bpf_trace.c:uprobe_prog_run(), the BPF program is executed
without recursion context protection:

        err = bpf_prog_run(link->link.prog, regs);

If a task executing uprobe_prog_run() is preempted (or yields) and the
preempting task triggers the same program on the same CPU, the private stack
can be overwritten, breaking verifier safety guarantees. Could we add
bpf_prog_get_recursion_context() protection to uprobe_prog_run() too?

> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index ffa5626411ac2..1d263992213e1 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
[ ... ]
>  static __always_inline u32
>  bpf_prog_run_array(const struct bpf_prog_array *array,
>  		   const void *ctx, bpf_prog_run_fn run_prog)
>  {
>  	const struct bpf_prog_array_item *item;
> -	const struct bpf_prog *prog;
> +	struct bpf_prog *prog;

[Severity: Low]
Was this const removal intended for bpf_prog_run_array_uprobe() instead?

Removing the const qualifier here doesn't seem necessary for
bpf_prog_run_array().

[ ... ]
> @@ -2640,15 +2648,30 @@ bpf_prog_run_array_uprobe(const struct bpf_prog_array *array,
>  	old_run_ctx = bpf_set_run_ctx(&run_ctx.run_ctx);
>  	item = &array->items[0];
>  	while ((prog = READ_ONCE(item->prog))) {
> +		/* dummy_bpf_prog has no recursion state. */
> +		if (unlikely(!prog->len)) {
> +			item++;
> +			continue;
> +		}
> +
> +		if (unlikely(!bpf_prog_get_recursion_context(prog))) {

[Severity: Low]
Does passing prog to bpf_prog_get_recursion_context() here cause a
build regression with a -Wdiscarded-qualifiers compiler warning?

Since prog is declared as const struct bpf_prog *prog in
bpf_prog_run_array_uprobe(), and bpf_prog_get_recursion_context() expects a
non-const pointer, this discards the const qualifier.

Should the const removal above have been applied here in
bpf_prog_run_array_uprobe() instead?

> +			bpf_prog_inc_misses_counter(prog);
> +			bpf_prog_put_recursion_context(prog);
> +			item++;
> +			continue;
> +		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1