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

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

[Leon Hwang]

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

It is because the verifier does not verify whether the symbol is a kernel
function or a bpf prog. That said, a sleepable tracing prog is allowed to
attach to a bpf prog target whose name has '__x64_'-alike prefix.

For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP
prog, and copies buffer from a user pointer with bpf_copy_from_user()
helper. After attaching the XDP prog to lo interface, the kernel BUG
could be triggered by 'ping -c 1 -W 1 127.0.0.1':

[    3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324

Fix it by disallowing sleepable tracing prog always when its target btf
is not kernel's btf.

Changes:
v2 -> v3:
* Use btf_is_kernel() instead of passing 'tgt_prog'. (per Andrii)
* v2: https://lore.kernel.org/bpf/20260725132624.78373-1-leon.hwang@linux.dev/

v1 -> v2:
* Drop redundant 'prog->sleepable' check. (per Viktor)
* Collect Acked-by from Viktor, Thanks.
* v1: https://lore.kernel.org/bpf/20260724141422.10463-1-leon.hwang@linux.dev/

Leon Hwang (2):
  bpf: Fix sleepable check for tracing prog
  selftests/bpf: Verify rejection of sleepable tracing prog

 kernel/bpf/verifier.c                         |  3 +
 .../selftests/bpf/prog_tests/fexit_bpf2bpf.c  | 57 +++++++++++++++++++
 .../selftests/bpf/progs/fentry_sleepable.c    | 18 ++++++
 tools/testing/selftests/bpf/progs/xdp_dummy.c |  6 ++
 4 files changed, 84 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/progs/fentry_sleepable.c

--
2.55.0

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

[Leon Hwang]

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

It is because the verifier does not verify whether the symbol is a kernel
function or a bpf prog. That said, a sleepable tracing prog is allowed to
attach to a bpf prog target whose name has '__x64_'-alike prefix.

For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP
prog, and copies buffer from a user pointer with bpf_copy_from_user()
helper. After attaching the XDP prog to lo interface, the kernel BUG
could be triggered by 'ping -c 1 -W 1 127.0.0.1':

[    3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324

Fix it by disallowing sleepable tracing prog always when its target btf
is not kernel's btf.

Fixes: 16d9c5660692 ("bpf: Always allow sleepable programs on syscalls")
Acked-by: Viktor Malik <vmalik@redhat.com>
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
 kernel/bpf/verifier.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index b274004fccfd..7bb541e343b2 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -19019,6 +19019,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;
+
 		t = btf_type_by_id(btf, btf_id);
 		if (!t)
 			return -EINVAL;
-- 
2.55.0

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

[sashiko-bot]

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

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

[Andrii Nakryiko]

On Tue, Aug 4, 2026 at 7:57 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> When CONFIG_FUNCTION_ERROR_INJECTION is disabled, a sleepable tracing prog
> is allowed to attach to '__x64_'-alike prefix symbols.
>
> It is because the verifier does not verify whether the symbol is a kernel
> function or a bpf prog. That said, a sleepable tracing prog is allowed to
> attach to a bpf prog target whose name has '__x64_'-alike prefix.
>
> For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP
> prog, and copies buffer from a user pointer with bpf_copy_from_user()
> helper. After attaching the XDP prog to lo interface, the kernel BUG
> could be triggered by 'ping -c 1 -W 1 127.0.0.1':
>
> [    3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324
>
> Fix it by disallowing sleepable tracing prog always when its target btf
> is not kernel's btf.
>
> Fixes: 16d9c5660692 ("bpf: Always allow sleepable programs on syscalls")
> Acked-by: Viktor Malik <vmalik@redhat.com>
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> ---
>  kernel/bpf/verifier.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index b274004fccfd..7bb541e343b2 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -19019,6 +19019,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;
> +

see sashiko reply, just move it outside of switch and disallow
sleepable for anything that is not kernel/module BTF, regardless of
program type

pw-bot: cr


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

Re: [PATCH bpf-next v3 2/2] selftests/bpf: Verify rejection of sleepable tracing prog

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The test contains dead reproducer code that intentionally crashes the kernel on test failure instead of failing gracefully.
--

--- Patch [2]: [PATCH bpf-next v3 2/2] selftests/bpf: Verify rejection of sleepable tracing prog ---
commit 22c464db2aa39d78b7ca52b202c4a7828b6fddc2
Author: Leon Hwang <leon.hwang@linux.dev>

selftests/bpf: Verify rejection of sleepable tracing prog

This commit adds a test to verify that a sleepable tracing program cannot
attach to a '__x64_sys' prefixed program target.

> diff --git a/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c b/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
> index 4a87d7163c8c7..2523c07a16c65 100644
> --- a/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
> +++ b/tools/testing/selftests/bpf/prog_tests/fexit_bpf2bpf.c
[ ... ]
> @@ -576,6 +577,60 @@ static void test_func_replace_progmap(void)
>  	freplace_progmap__destroy(skel);
>  }
>  
> +static void test_sleepable_fentry_to_xdp(void)
> +{
[ ... ]
> +	err = fentry_sleepable__load(skel);
> +	ASSERT_ERR(err, "fentry_sleepable__load");
> +	if (err)
> +		goto out;
> +
> +	skel->links.fentry_xdp = bpf_program__attach_trace(skel->progs.fentry_xdp);
> +	if (!ASSERT_OK_PTR(skel->links.fentry_xdp, "bpf_program__attach_trace"))
> +		goto out;
> +
> +	skel_xdp->links.__x64_sys_nop = bpf_program__attach_xdp(skel_xdp->progs.__x64_sys_nop,
> +								ifindex);
> +	if (!ASSERT_OK_PTR(skel_xdp->links.__x64_sys_nop, "bpf_program__attach_xdp"))
> +		goto out;
> +
> +	err = system("ping -q -c 1 -W 1 127.0.0.1 > /dev/null");
> +	ASSERT_OK(err, "ping");
> +	ASSERT_ERR(skel->bss->retval, "retval");

[Severity: Medium]
Will this sequence crash the kernel if the test fails?

If the kernel lacks the fix, fentry_sleepable__load() will return 0.
ASSERT_ERR() will correctly log a test failure, but since err == 0, the
if (err) goto out; check will be bypassed.

The test will then proceed to attach the sleepable program and trigger it
with ping, intentionally causing the kernel panic described in the commit
message.

Additionally, when the kernel is fixed and the test passes, this entire block
is dead code because fentry_sleepable__load() returns < 0 and the test exits
early via goto out.

Could this test fail gracefully without crashing the system during automated
bisections?

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