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

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 allo=
ws non-sleepable tracing programs to call `bpf_d_path`, leading to kernel d=
eadlocks.
--

--- Patch [1]: [PATCH bpf-next v3 1/2] bpf: Fix sleepable check for tracing=
 prog ---
commit bd029887d83c0773bad79aca8216a06849cdbd32
Author: Leon Hwang <[email protected]>

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, uns=
igned long addr, const struct b
> =20
>  	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 =3D btf_type_by_id(btf, btf_id);
>  		if (!t)
>  			return -EINVAL;

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804145710.4306=
[email protected]?part=3D1