AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "check_max_stack_depth_subprog",
    "check_max_stack_depth"
  ],
  "Reasoning": "The patch modifies the BPF verifier's stack depth checking logic to reject tail calls within any callback, not just exception callbacks. This is a functional change in the core BPF verifier that affects program loading and validation.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit addee6c49a626d30ef51445cefe08a975e5f44e5\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Jul 14 06:37:37 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c\nindex 03e2202cca13d5..3f6c8b8fc04d08 100644\n--- a/kernel/bpf/verifier.c\n+++ b/kernel/bpf/verifier.c\n@@ -5258,10 +5258,6 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,\n \t\tif (verifier_bug_if(sidx \u003c 0, env, \"callee not found at insn %d\", next_insn))\n \t\t\treturn -EFAULT;\n \t\tif (subprog[sidx].is_async_cb) {\n-\t\t\tif (subprog[sidx].has_tail_call) {\n-\t\t\t\tverifier_bug(env, \"subprog has tail_call and async cb\");\n-\t\t\t\treturn -EFAULT;\n-\t\t\t}\n \t\t\t/* async callbacks don't increase bpf prog stack size unless called directly */\n \t\t\tif (!bpf_pseudo_call(insn + i))\n \t\t\t\tcontinue;\n@@ -5302,8 +5298,8 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,\n \t */\n \tif (tail_call_reachable) {\n \t\tfor (tmp = idx; tmp \u003e= 0; tmp = dinfo[tmp].caller) {\n-\t\t\tif (subprog[tmp].is_exception_cb) {\n-\t\t\t\tverbose(env, \"cannot tail call within exception cb\\n\");\n+\t\t\tif (subprog[tmp].is_cb) {\n+\t\t\t\tverbose(env, \"cannot tail call within callback\\n\");\n \t\t\t\treturn -EINVAL;\n \t\t\t}\n \t\t\tif (subprog[tmp].stack_arg_cnt) {\ndiff --git a/tools/testing/selftests/bpf/prog_tests/tailcalls.c b/tools/testing/selftests/bpf/prog_tests/tailcalls.c\nindex a5a226d0104cd2..6fbf4c37e234cc 100644\n--- a/tools/testing/selftests/bpf/prog_tests/tailcalls.c\n+++ b/tools/testing/selftests/bpf/prog_tests/tailcalls.c\n@@ -12,6 +12,7 @@\n #include \"tailcall_cgrp_storage_no_storage.skel.h\"\n #include \"tailcall_cgrp_storage.skel.h\"\n #include \"tailcall_sleepable.skel.h\"\n+#include \"tailcall_bpf2bpf_callback.skel.h\"\n \n /* test_tailcall_1 checks basic functionality by patching multiple locations\n  * in a single program for a single tail call slot with nop-\u003ejmp, jmp-\u003enop\n@@ -1901,6 +1902,11 @@ static void test_tailcall_sleepable(void)\n \ttailcall_sleepable__destroy(skel);\n }\n \n+static void test_tailcall_bpf2bpf_callback(void)\n+{\n+\tRUN_TESTS(tailcall_bpf2bpf_callback);\n+}\n+\n void test_tailcalls(void)\n {\n \tif (test__start_subtest(\"tailcall_1\"))\n@@ -1967,4 +1973,5 @@ void test_tailcalls(void)\n \t\ttest_tailcall_cgrp_storage_no_storage_leaf();\n \tif (test__start_subtest(\"tailcall_cgrp_storage_no_storage_bridge\"))\n \t\ttest_tailcall_cgrp_storage_no_storage_bridge();\n+\ttest_tailcall_bpf2bpf_callback();\n }\ndiff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c\nnew file mode 100644\nindex 00000000000000..dfe9c49cfeb1de\n--- /dev/null\n+++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c\n@@ -0,0 +1,62 @@\n+// SPDX-License-Identifier: GPL-2.0\n+#include \u003clinux/bpf.h\u003e\n+#include \u003cbpf/bpf_helpers.h\u003e\n+#include \"bpf_misc.h\"\n+#include \"bpf_test_utils.h\"\n+\n+int classifier_0(struct __sk_buff *skb);\n+\n+struct {\n+\t__uint(type, BPF_MAP_TYPE_PROG_ARRAY);\n+\t__uint(max_entries, 1);\n+\t__uint(key_size, sizeof(__u32));\n+\t__array(values, void (void));\n+} jmp_table SEC(\".maps\") = {\n+\t.values = {\n+\t\t[0] = (void *) \u0026classifier_0,\n+\t},\n+};\n+\n+static __noinline\n+int subprog_tail0(struct __sk_buff *skb)\n+{\n+\tint ret = 0;\n+\n+\tbpf_tail_call_static(skb, \u0026jmp_table, 1);\n+\tbarrier_var(ret);\n+\treturn ret;\n+}\n+\n+__auxiliary\n+SEC(\"tc\")\n+int classifier_0(struct __sk_buff *skb)\n+{\n+\tint ret;\n+\n+\tret = subprog_tail0(skb);\n+\t__sink(ret);\n+\treturn 0;\n+}\n+\n+static __noinline\n+int callback_loop(int index, void **cb_ctx)\n+{\n+\tint ret;\n+\n+\tret = subprog_tail0(*cb_ctx);\n+\tbarrier_var(ret);\n+\treturn ret ? 1 : 0;\n+}\n+\n+/* callback involving subprog with tail call is rejected */\n+SEC(\"tc\")\n+__failure __msg(\"cannot tail call within callback\")\n+int tailcall_bpf2bpf_callback(struct __sk_buff *skb)\n+{\n+\tclobber_regs_stack();\n+\n+\tbpf_loop(1, callback_loop, \u0026skb, 0);\n+\treturn 0;\n+}\n+\n+char __license[] SEC(\"license\") = \"GPL\";\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "check_max_stack_depth_subprog",
    "check_max_stack_depth"
  ],
  "Reasoning": "The patch modifies the BPF verifier's stack depth checking logic to reject tail calls within any callback, not just exception callbacks. This is a functional change in the core BPF verifier that affects program loading and validation.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit addee6c49a626d30ef51445cefe08a975e5f44e5
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Jul 14 06:37:37 2026 +0000

    syz-cluster: applied patch under review

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 03e2202cca13d5..3f6c8b8fc04d08 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5258,10 +5258,6 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
 		if (verifier_bug_if(sidx < 0, env, "callee not found at insn %d", next_insn))
 			return -EFAULT;
 		if (subprog[sidx].is_async_cb) {
-			if (subprog[sidx].has_tail_call) {
-				verifier_bug(env, "subprog has tail_call and async cb");
-				return -EFAULT;
-			}
 			/* async callbacks don't increase bpf prog stack size unless called directly */
 			if (!bpf_pseudo_call(insn + i))
 				continue;
@@ -5302,8 +5298,8 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
 	 */
 	if (tail_call_reachable) {
 		for (tmp = idx; tmp >= 0; tmp = dinfo[tmp].caller) {
-			if (subprog[tmp].is_exception_cb) {
-				verbose(env, "cannot tail call within exception cb\n");
+			if (subprog[tmp].is_cb) {
+				verbose(env, "cannot tail call within callback\n");
 				return -EINVAL;
 			}
 			if (subprog[tmp].stack_arg_cnt) {
diff --git a/tools/testing/selftests/bpf/prog_tests/tailcalls.c b/tools/testing/selftests/bpf/prog_tests/tailcalls.c
index a5a226d0104cd2..6fbf4c37e234cc 100644
--- a/tools/testing/selftests/bpf/prog_tests/tailcalls.c
+++ b/tools/testing/selftests/bpf/prog_tests/tailcalls.c
@@ -12,6 +12,7 @@
 #include "tailcall_cgrp_storage_no_storage.skel.h"
 #include "tailcall_cgrp_storage.skel.h"
 #include "tailcall_sleepable.skel.h"
+#include "tailcall_bpf2bpf_callback.skel.h"
 
 /* test_tailcall_1 checks basic functionality by patching multiple locations
  * in a single program for a single tail call slot with nop->jmp, jmp->nop
@@ -1901,6 +1902,11 @@ static void test_tailcall_sleepable(void)
 	tailcall_sleepable__destroy(skel);
 }
 
+static void test_tailcall_bpf2bpf_callback(void)
+{
+	RUN_TESTS(tailcall_bpf2bpf_callback);
+}
+
 void test_tailcalls(void)
 {
 	if (test__start_subtest("tailcall_1"))
@@ -1967,4 +1973,5 @@ void test_tailcalls(void)
 		test_tailcall_cgrp_storage_no_storage_leaf();
 	if (test__start_subtest("tailcall_cgrp_storage_no_storage_bridge"))
 		test_tailcall_cgrp_storage_no_storage_bridge();
+	test_tailcall_bpf2bpf_callback();
 }
diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c
new file mode 100644
index 00000000000000..dfe9c49cfeb1de
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/bpf.h>
+#include <bpf/bpf_helpers.h>
+#include "bpf_misc.h"
+#include "bpf_test_utils.h"
+
+int classifier_0(struct __sk_buff *skb);
+
+struct {
+	__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
+	__uint(max_entries, 1);
+	__uint(key_size, sizeof(__u32));
+	__array(values, void (void));
+} jmp_table SEC(".maps") = {
+	.values = {
+		[0] = (void *) &classifier_0,
+	},
+};
+
+static __noinline
+int subprog_tail0(struct __sk_buff *skb)
+{
+	int ret = 0;
+
+	bpf_tail_call_static(skb, &jmp_table, 1);
+	barrier_var(ret);
+	return ret;
+}
+
+__auxiliary
+SEC("tc")
+int classifier_0(struct __sk_buff *skb)
+{
+	int ret;
+
+	ret = subprog_tail0(skb);
+	__sink(ret);
+	return 0;
+}
+
+static __noinline
+int callback_loop(int index, void **cb_ctx)
+{
+	int ret;
+
+	ret = subprog_tail0(*cb_ctx);
+	barrier_var(ret);
+	return ret ? 1 : 0;
+}
+
+/* callback involving subprog with tail call is rejected */
+SEC("tc")
+__failure __msg("cannot tail call within callback")
+int tailcall_bpf2bpf_callback(struct __sk_buff *skb)
+{
+	clobber_regs_stack();
+
+	bpf_loop(1, callback_loop, &skb, 0);
+	return 0;
+}
+
+char __license[] SEC("license") = "GPL";

gemini-3.1-pro-preview

null

null

							input: 3231
							output: 38
							thoughts: 168
						

**Analyzing a BPF Verifier Patch**

Okay, so I'm looking at this patch that tweaks the BPF verifier, specifically in `kernel/bpf/verifier.c`. My immediate focus is on how it modifies the `check_max_stack_depth_subprog` function. It seems like the patch is removing a couple of checks related to whether a subprogram (`subprog[sidx]`) has a tail call or is an asynchronous callback (`has_tail_call`, `is_async_cb`). That piques my interest – why are they removing those specific checks? Are they simplifying the logic, or is there a subtle change in how tail calls or callbacks are handled that necessitates this?

Then there's a modification within the `tail_call_reachable` block. It looks like `subprog[tmp].is_exception_cb` is being changed to `subprog[tmp].is_cb`. Now, that's interesting. It looks like an exception callback is being generalized to a generic callback. I'll need to dig deeper into the context of `tail_call_reachable` to understand the implications of this change. Why are they broadening the scope? Is it to accommodate a new kind of callback behavior, or is it a refactoring to make the code cleaner or more efficient?

Finally, the patch includes a new test case in `tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_callback.c`. That's good – a test case gives me some insight into the intended behavior. It specifically mentions `tailcall_bpf2bpf_callback`, which makes me suspect that this patch is changing the way tail calls are used between BPF programs within callbacks. I'll need to look at this test case thoroughly to understand the scenario it's designed to cover and how it validates the patch's changes.

Before I go further, I should really check `kernel/bpf/verifier.c` to get the lay of the land and understand the surrounding logic. Then, I will be able to tell if these changes are sound, efficient, and aligned with the overall goals of the BPF subsystem.

{
  "Expression": "check_max_stack_depth_subprog",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=5137=struct bpf_subprog_call_depth_info {\n--\nkernel/bpf/verifier.c-5146- */\nkernel/bpf/verifier.c:5147:static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,\nkernel/bpf/verifier.c-5148-\t\t\t\t\t struct bpf_subprog_call_depth_info *dinfo,\n--\nkernel/bpf/verifier.c=5340=static int check_max_stack_depth(struct bpf_verifier_env *env)\n--\nkernel/bpf/verifier.c-5372-\t\t\tpriv_stack_supported = !i \u0026\u0026 priv_stack_mode == PRIV_STACK_ADAPTIVE;\nkernel/bpf/verifier.c:5373:\t\t\tret = check_max_stack_depth_subprog(env, i, dinfo,\nkernel/bpf/verifier.c-5374-\t\t\t\t\tpriv_stack_supported);\n"
}

gemini-3.1-pro-preview

null

null

							input: 4166
							output: 31
							thoughts: 408
						

**Analyzing a BPF Verifier Change**

Okay, so I'm looking at a patch that fundamentally alters the BPF verifier's logic, specifically concerning tail calls within callbacks. Before, the verifier had a very specific check: a tail call wasn't allowed within an exception callback and also not in a async callback.

Now, the code enforces a stricter rule: tail calls are prohibited within *any* callback, regardless of whether it's an exception or async one. The snippet I see shows the change.

```c
	if (tail_call_reachable) {
		for (tmp = idx; tmp >= 0; tmp = dinfo[tmp].caller) {
			if (subprog[tmp].is_cb) {
				verbose(env, "cannot tail call within callback\n");
				return -EINVAL;
			}
```

This is definitely a functional change with wide-reaching implications, given the verifier's central role in the BPF subsystem. This makes it a prime candidate for fuzzing to ensure it handles all sorts of edge cases robustly.

I need to focus my fuzzing efforts here. The key functions to investigate are `check_max_stack_depth_subprog`, and `check_max_stack_depth`, as the former is the one actually modified, and the latter is the entry point.

I should also double-check whether this behavior is dependent on any specific configurations. I know the BPF verifier itself is enabled by `CONFIG_BPF_SYSCALL`, but I need to make sure there aren't any other configuration options that modify how these rules are applied.

no matches

{
  "Expression": "config BPF_SYSCALL",
  "PathPrefix": "init/Kconfig"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 4971
							output: 27
							thoughts: 16
						

Here's my thought process, summarized as you requested:

**Locating the Heart of the Matter: `BPF_SYSCALL`**

Alright, let's get down to brass tacks. I need to understand where `BPF_SYSCALL` is defined. This is a crucial piece of the puzzle, and without knowing its origin, my understanding of the relevant BPF code or system calls will remain incomplete. My expertise allows me to immediately recognize this as a key identifier, likely a macro, enum, or symbolic constant crucial to BPF interactions with the kernel's system call interface. I'll need to trace its definition to clarify its purpose and value. This is the starting point for really digging into this area. Where is the definition? Let's start the hunt.

{
  "Expression": "config BPF_SYSCALL",
  "PathPrefix": ""
}

{
  "Output": "kernel/bpf/Kconfig=25=menu \"BPF subsystem\"\nkernel/bpf/Kconfig-26-\nkernel/bpf/Kconfig:27:config BPF_SYSCALL\nkernel/bpf/Kconfig-28-\tbool \"Enable bpf() system call\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5263
							output: 35
							thoughts: 42
						

Here's my take on the thought process, as if it were my own:

**Analyzing BPF Stack Depth Limits**

Okay, so we're diving into BPF stack depth limits, and the key configuration item I'm immediately focusing on is `CONFIG_BPF_SYSCALL`. That's the primary switch, the linchpin. Everything related to BPF syscalls hinges on this, and ensuring it's properly configured is the first critical step.

Now, let's get into the specifics of how stack depth is managed. I need to refresh my memory on the critical checks. I'm thinking, I need to check how the checks themselves work. I need to consider `check_max_stack_depth_subprog` and `check_max_stack_depth`. I know these are related, but I need to quickly run through them to determine if I missed a potential optimization. What specifically do they cover? How are these limits enforced? What's the relationship between the checks applied to subprograms and the broader, overall limit? I need to ensure they are consistent and accurate.

{
  "Expression": "check_max_stack_depth",
  "PathPrefix": "kernel/bpf/verifier.c"
}

{
  "Output": "kernel/bpf/verifier.c=5137=struct bpf_subprog_call_depth_info {\n--\nkernel/bpf/verifier.c-5146- */\nkernel/bpf/verifier.c:5147:static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,\nkernel/bpf/verifier.c-5148-\t\t\t\t\t struct bpf_subprog_call_depth_info *dinfo,\n--\nkernel/bpf/verifier.c-5339-\nkernel/bpf/verifier.c:5340:static int check_max_stack_depth(struct bpf_verifier_env *env)\nkernel/bpf/verifier.c-5341-{\n--\nkernel/bpf/verifier.c-5372-\t\t\tpriv_stack_supported = !i \u0026\u0026 priv_stack_mode == PRIV_STACK_ADAPTIVE;\nkernel/bpf/verifier.c:5373:\t\t\tret = check_max_stack_depth_subprog(env, i, dinfo,\nkernel/bpf/verifier.c-5374-\t\t\t\t\tpriv_stack_supported);\n--\nkernel/bpf/verifier.c=20042=int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,\n--\nkernel/bpf/verifier.c-20231-\tif (ret == 0)\nkernel/bpf/verifier.c:20232:\t\tret = check_max_stack_depth(env);\nkernel/bpf/verifier.c-20233-\n"
}

gemini-3.1-pro-preview

null

null

							input: 5989
							output: 29
							thoughts: 67
						

Here's my summary, as the expert:

**Investigating BPF Stack Depth Checks**

Okay, so `check_max_stack_depth` is called directly from `bpf_check` – that’s a good starting point for a deeper dive. It's clearly a focal point for understanding stack depth limitations within the BPF verifier.

My next step is to explore related configurations. I need to figure out if there are any other relevant settings or flags that might influence this particular check. Now, the patch focuses on `kernel/bpf/verifier.c`. My immediate thought is, *is* this file compiled conditionally? Are there `#ifdef` blocks or build options that would cause this specific part of the code to be enabled or disabled? I have to account for build variations.

{
  "Expression": "verifier.o",
  "PathPrefix": "kernel/bpf/Makefile"
}

{
  "Output": "kernel/bpf/Makefile=7=CFLAGS_core.o += -Wno-override-init $(cflags-nogcse-yy)\nkernel/bpf/Makefile-8-\nkernel/bpf/Makefile:9:obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o cnum.o log.o token.o liveness.o const_fold.o\nkernel/bpf/Makefile-10-obj-$(CONFIG_BPF_SYSCALL) += bpf_iter.o map_iter.o task_iter.o prog_iter.o link_iter.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 6416
							output: 107
							thoughts: 153
						

**Analyzing the BPF Verifier Patch**

Okay, so I'm looking at this patch and the first thing that jumps out is that it's dealing with `CONFIG_BPF_SYSCALL`. That immediately flags it as something potentially performance-critical, since BPF syscalls can be a bottleneck. The core of the change seems to be around `check_max_stack_depth_subprog`, and I see it's a static function. That suggests this is a localized change, although "localized" in the kernel can still have broad implications, especially in the verifier. I need to keep `check_max_stack_depth_subprog` and `check_max_stack_depth` at the front of my mind.

Now, what's it actually *doing*? Ah, it's modifying the stack depth checking logic *within* the BPF verifier. This is important. It looks like the patch is adding a restriction: rejecting tail calls within *any* callback, not just exception callbacks. That's a functional change, a core modification to how programs are loaded and validated. This could affect a bunch of existing programs, and possibly performance. The "WorthFuzzing" flag confirms that it is likely to have security implications. The important thing is that `BPF_SYSCALL` is enabled, which suggests the need for extra scrutiny here. I see the main focus is around the `check_max_stack_depth_subprog` and `check_max_stack_depth` functions. Okay, I'll need to dig into the exact verification logic around those functions.

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "check_max_stack_depth_subprog",
    "check_max_stack_depth"
  ],
  "Reasoning": "The patch modifies the BPF verifier's stack depth checking logic to reject tail calls within any callback, not just exception callbacks. This is a functional change in the core BPF verifier that affects program loading and validation.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "check_max_stack_depth_subprog",
    "check_max_stack_depth"
  ],
  "Reasoning": "The patch modifies the BPF verifier's stack depth checking logic to reject tail calls within any callback, not just exception callbacks. This is a functional change in the core BPF verifier that affects program loading and validation.",
  "WorthFuzzing": true
}