Re: [PATCH bpf-next v3 1/2] bpf: Fix sleepable check for tracing prog

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Bypass of `bpf_d_path_allowed` allowlist using forged BTF IDs allows non-sleepable tracing programs to call `bpf_d_path`, leading to kernel deadlocks.
--

--- Patch [1]: [PATCH bpf-next v3 1/2] bpf: Fix sleepable check for tracing prog ---
commit bd029887d83c0773bad79aca8216a06849cdbd32
Author: Leon Hwang <leon.hwang@linux.dev>

bpf: Fix sleepable check for tracing prog

When CONFIG_FUNCTION_ERROR_INJECTION is disabled, a sleepable tracing prog
is allowed to attach to '__x64_'-alike prefix symbols.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7439afdc851a7..d4541cca7180e 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -19024,6 +19024,9 @@ static int btf_id_allow_sleepable(u32 btf_id, unsigned long addr, const struct b
>  
>  	switch (prog->type) {
>  	case BPF_PROG_TYPE_TRACING:
> +		if (!btf_is_kernel(btf))
> +			return -EINVAL;
> +

[Severity: High]
This is a pre-existing issue, but does the same bypass exist for
non-sleepable tracing programs calling bpf_d_path()?

Looking at bpf_d_path_allowed() in kernel/trace/bpf_trace.c:

kernel/trace/bpf_trace.c:bpf_d_path_allowed() {
	...
	return btf_id_set_contains(&btf_allowlist_d_path,
				   prog->aux->attach_btf_id);
}

This check relies entirely on the integer attach_btf_id and fails to verify
if attach_btf is the kernel's vmlinux BTF.

Can a user load a dummy BPF program with a crafted BTF where a function's
BTF ID exactly matches an ID in btf_allowlist_d_path, and then attach a
non-sleepable tracing program to it?

If this dummy program is triggered in softirq context by network traffic,
and the tracing program extracts a valid path and calls bpf_d_path(),
this would invoke d_path() which attempts to acquire rename_lock (a seqlock).

If the softirq interrupts a process holding the seqlock writer spinlock,
wouldn't read_seqbegin_or_lock() retry and fall back to taking the spinlock,
causing a deadlock on the same CPU?

>  		t = btf_type_by_id(btf, btf_id);
>  		if (!t)
>  			return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804145710.43062-1-leon.hwang@linux.dev?part=1