AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "bpf_do_misc_fixups",
    "__bpf_prog_select_runtime"
  ],
  "Reasoning": "The patch adds logic to reject BPF programs if they require JIT compilation (e.g., because the JIT inlines a helper call) but JIT is unavailable or fails. This is a functional change in the core BPF verifier/loader and should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit c05fbea71bccaa2f617313fdd724b72335c27df9\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Jul 2 11:37:23 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/include/linux/bpf.h b/include/linux/bpf.h\nindex ba09795e0bfdb7..f5c283af3cf786 100644\n--- a/include/linux/bpf.h\n+++ b/include/linux/bpf.h\n@@ -1889,6 +1889,7 @@ struct bpf_prog {\n \t\tu8 digest[SHA256_DIGEST_SIZE];\n \t\tu8 tag[BPF_TAG_SIZE];\n \t};\n+\tu8\t\t\tjit_required;\t/* program strictly requires JIT compiler */\n \tstruct bpf_prog_stats __percpu *stats;\n \tu8 __percpu\t\t*active;\t/* u8[BPF_NR_CONTEXTS] for recursion protection */\n \tunsigned int\t\t(*bpf_func)(const void *ctx,\ndiff --git a/kernel/bpf/core.c b/kernel/bpf/core.c\nindex 649cce41e13f3b..a55754bcc5935a 100644\n--- a/kernel/bpf/core.c\n+++ b/kernel/bpf/core.c\n@@ -2639,7 +2639,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct\n \n \t\tfp = bpf_prog_jit_compile(env, fp);\n \t\tbpf_prog_jit_attempt_done(fp);\n-\t\tif (!fp-\u003ejited \u0026\u0026 jit_needed) {\n+\t\tif (!fp-\u003ejited \u0026\u0026 (jit_needed || fp-\u003ejit_required)) {\n \t\t\t*err = -ENOTSUPP;\n \t\t\treturn fp;\n \t\t}\ndiff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c\nindex 12a8a4eb757f18..94e0457a0aa33a 100644\n--- a/kernel/bpf/fixups.c\n+++ b/kernel/bpf/fixups.c\n@@ -1841,8 +1841,10 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)\n \t\t}\n \n \t\t/* Skip inlining the helper call if the JIT does it. */\n-\t\tif (bpf_jit_inlines_helper_call(insn-\u003eimm))\n+\t\tif (bpf_jit_inlines_helper_call(insn-\u003eimm)) {\n+\t\t\tprog-\u003ejit_required = 1;\n \t\t\tgoto next_insn;\n+\t\t}\n \n \t\tif (insn-\u003eimm == BPF_FUNC_get_route_realm)\n \t\t\tprog-\u003edst_needed = 1;\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "bpf_do_misc_fixups",
    "__bpf_prog_select_runtime"
  ],
  "Reasoning": "The patch adds logic to reject BPF programs if they require JIT compilation (e.g., because the JIT inlines a helper call) but JIT is unavailable or fails. This is a functional change in the core BPF verifier/loader and should be fuzzed.",
  "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 c05fbea71bccaa2f617313fdd724b72335c27df9
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Jul 2 11:37:23 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index ba09795e0bfdb7..f5c283af3cf786 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1889,6 +1889,7 @@ struct bpf_prog {
 		u8 digest[SHA256_DIGEST_SIZE];
 		u8 tag[BPF_TAG_SIZE];
 	};
+	u8			jit_required;	/* program strictly requires JIT compiler */
 	struct bpf_prog_stats __percpu *stats;
 	u8 __percpu		*active;	/* u8[BPF_NR_CONTEXTS] for recursion protection */
 	unsigned int		(*bpf_func)(const void *ctx,
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 649cce41e13f3b..a55754bcc5935a 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -2639,7 +2639,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct
 
 		fp = bpf_prog_jit_compile(env, fp);
 		bpf_prog_jit_attempt_done(fp);
-		if (!fp->jited && jit_needed) {
+		if (!fp->jited && (jit_needed || fp->jit_required)) {
 			*err = -ENOTSUPP;
 			return fp;
 		}
diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 12a8a4eb757f18..94e0457a0aa33a 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -1841,8 +1841,10 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
 		}
 
 		/* Skip inlining the helper call if the JIT does it. */
-		if (bpf_jit_inlines_helper_call(insn->imm))
+		if (bpf_jit_inlines_helper_call(insn->imm)) {
+			prog->jit_required = 1;
 			goto next_insn;
+		}
 
 		if (insn->imm == BPF_FUNC_get_route_realm)
 			prog->dst_needed = 1;

gemini-3.1-pro-preview

null

null

							input: 2319
							output: 25
							thoughts: 132
						

**Analyzing the BPF Core Modification**

Okay, so I'm looking at this patch modifying the BPF core. It seems they've added a `jit_required` flag to the `struct bpf_prog` structure. Intuitively, this suggests they're trying to control JIT compilation in a more granular way.

From what I can tell, `bpf_do_misc_fixups` is where this flag gets set. If a particular helper call instruction (`insn->imm`) requires inlining according to `bpf_jit_inlines_helper_call`, then the `prog->jit_required` flag is set to 1. This is fairly standard; helper inlining often necessitates JIT.

Now, in `__bpf_prog_select_runtime`, this flag comes into play. If the program isn't already JIT'd (`!fp->jited`) and either JIT compilation is needed explicitly through `jit_needed` OR the `jit_required` flag is set, the function returns `-ENOTSUPP`. This implies a hard failure. The implication is, if the JIT is mandatory and not available, the program will not run. This is a bit rigid, but it might be necessary for certain security contexts, or for programs relying on specific JIT optimizations.

My next step is to examine the `bpf_jit_inlines_helper_call` function. I need to understand what criteria trigger this helper inlining, as that will be key to understanding the full implications of this change. Is this about performance, security, or something else entirely? The types of helper functions that trigger this inlining will provide the answer.

{
  "Expression": "bpf_jit_inlines_helper_call"
}

{
  "Output": "arch/arm64/net/bpf_jit_comp.c=3201=bool bpf_jit_supports_timed_may_goto(void)\n--\narch/arm64/net/bpf_jit_comp.c-3205-\narch/arm64/net/bpf_jit_comp.c:3206:bool bpf_jit_inlines_helper_call(s32 imm)\narch/arm64/net/bpf_jit_comp.c-3207-{\n--\narch/powerpc/net/bpf_jit_comp.c=572=bool bpf_jit_supports_percpu_insn(void)\n--\narch/powerpc/net/bpf_jit_comp.c-576-\narch/powerpc/net/bpf_jit_comp.c:577:bool bpf_jit_inlines_helper_call(s32 imm)\narch/powerpc/net/bpf_jit_comp.c-578-{\n--\narch/riscv/net/bpf_jit_comp64.c=2139=bool bpf_jit_supports_percpu_insn(void)\n--\narch/riscv/net/bpf_jit_comp64.c-2143-\narch/riscv/net/bpf_jit_comp64.c:2144:bool bpf_jit_inlines_helper_call(s32 imm)\narch/riscv/net/bpf_jit_comp64.c-2145-{\n--\narch/s390/net/bpf_jit_comp.c=3081=bool bpf_jit_supports_timed_may_goto(void)\n--\narch/s390/net/bpf_jit_comp.c-3085-\narch/s390/net/bpf_jit_comp.c:3086:bool bpf_jit_inlines_helper_call(s32 imm)\narch/s390/net/bpf_jit_comp.c-3087-{\n--\ninclude/linux/filter.h=1179=bool bpf_jit_needs_zext(void);\ninclude/linux/filter.h:1180:bool bpf_jit_inlines_helper_call(s32 imm);\ninclude/linux/filter.h-1181-bool bpf_jit_supports_subprog_tailcalls(void);\n--\nkernel/bpf/core.c=3209=bool __weak bpf_jit_bypass_spec_v4(void)\n--\nkernel/bpf/core.c-3219- */\nkernel/bpf/core.c:3220:bool __weak bpf_jit_inlines_helper_call(s32 imm)\nkernel/bpf/core.c-3221-{\n--\nkernel/bpf/fixups.c=1481=int bpf_do_misc_fixups(struct bpf_verifier_env *env)\n--\nkernel/bpf/fixups.c-1843-\t\t/* Skip inlining the helper call if the JIT does it. */\nkernel/bpf/fixups.c:1844:\t\tif (bpf_jit_inlines_helper_call(insn-\u003eimm)) {\nkernel/bpf/fixups.c-1845-\t\t\tprog-\u003ejit_required = 1;\n--\nkernel/bpf/verifier.c=16683=bool bpf_get_call_summary(struct bpf_verifier_env *env, struct bpf_insn *call,\n--\nkernel/bpf/verifier.c-16696-\t\t\t       (bpf_verifier_inlines_helper_call(env, call-\u003eimm) ||\nkernel/bpf/verifier.c:16697:\t\t\t\tbpf_jit_inlines_helper_call(call-\u003eimm));\nkernel/bpf/verifier.c-16698-\t\tcs-\u003eis_void = fn-\u003eret_type == RET_VOID;\n"
}

gemini-3.1-pro-preview

null

null

							input: 3843
							output: 23
							thoughts: 119
						

**Analyzing a BPF Security Patch**

Okay, so this patch is touching some pretty critical BPF internals – specifically, `bpf_do_misc_fixups` and `__bpf_prog_select_runtime`. These are foundational functions. What it's doing, essentially, is adding logic to *reject* BPF programs if they *need* JIT compilation but can't get it, either because JIT isn't enabled or because it's failed. That's a classic defense-in-depth approach, preventing potentially unsafe programs from executing if a critical component is missing.

This is immediately screaming "fuzzing target" to me. Any logic change in a security-sensitive area like this deserves a thorough fuzzing campaign to identify edge cases, potential bypasses, or unexpected behavior.

I need to focus my fuzzing efforts on those two core symbols: `bpf_do_misc_fixups` and `__bpf_prog_select_runtime`. They are the gatekeepers here.

Let me also verify the `BPF_SYSCALL` config is relevant here, given the syscall interface is key to BPF's operation. I should also check if any other configs might indirectly influence this code path or its behavior. I need to make sure I have a complete picture.

{
  "Expression": "__bpf_prog_select_runtime"
}

{
  "Output": "include/linux/filter.h=1128=sk_filter_reason(struct sock *sk, struct sk_buff *skb)\n--\ninclude/linux/filter.h-1132-\ninclude/linux/filter.h:1133:struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct bpf_prog *fp,\ninclude/linux/filter.h-1134-\t\t\t\t\t   int *err);\n--\nkernel/bpf/core.c=2564=static struct bpf_prog *bpf_prog_jit_compile(struct bpf_verifier_env *env, struct bpf_prog *prog)\n--\nkernel/bpf/core.c-2610-\nkernel/bpf/core.c:2611:struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct bpf_prog *fp,\nkernel/bpf/core.c-2612-\t\t\t\t\t   int *err)\n--\nkernel/bpf/core.c=2678=struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)\nkernel/bpf/core.c-2679-{\nkernel/bpf/core.c:2680:\treturn __bpf_prog_select_runtime(NULL, fp, err);\nkernel/bpf/core.c-2681-}\n--\nkernel/bpf/verifier.c=19743=int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr,\n--\nkernel/bpf/verifier.c-20007-\nkernel/bpf/verifier.c:20008:\tenv-\u003eprog = __bpf_prog_select_runtime(env, env-\u003eprog, \u0026ret);\nkernel/bpf/verifier.c-20009-\n"
}

gemini-3.1-pro-preview

null

null

							input: 4758
							output: 21
							thoughts: 68
						

Here's my summary, as though I'm thinking through this process:

**Investigating BPF Runtime Selection**

Okay, so I'm digging into how the BPF runtime is selected. I remember seeing `bpf_do_misc_fixups` and that function's in `kernel/bpf/fixups.c`. That makes sense; it's likely involved in setting up the BPF environment. Then there's `__bpf_prog_select_runtime`, which I seem to recall is in `kernel/bpf/core.c`. Ah, yes, the core logic should be in `core.c`.

Now, the question is, how simple is the configuration here? Is it as straightforward as just enabling `BPF_SYSCALL`? That would be nice. I need to verify if that's the only config flag I need to be aware of when considering the runtime selection. That's where I should start. Let's see if that's the sole dependency.

{
  "Expression": "config BPF_SYSCALL"
}

{
  "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: 5147
							output: 20
							thoughts: 147
						

Here's my analysis of the provided information, as if these are my immediate thoughts:

**Dissecting This BPF JIT Context**

Okay, so we're primarily focused on the **`BPF_SYSCALL`** aspect of this. That's the core system call interface, naturally. But, hold on...this is more nuanced than it initially appears. My mental map flags that **`bpf_jit_inlines_helper_call`** is actually implemented across *multiple* architectures: `arm64`, `powerpc`, `riscv`, and `s390`. A quick double-check reveals a weak implementation within `kernel/bpf/core.c` as well. That’s something I need to keep in mind; the specifics might vary considerably based on the target architecture.

Given that the context revolves around the JIT (Just-In-Time) compilation, I assume the patch is likely directly related to improving, fixing, or extending the BPF JIT capabilities. This is consistent with the need for the **`BPF_JIT`** configuration option to be enabled for effective testing. I immediately recall that this config option impacts how the BPF JIT compiler is enabled on a given system. Consequently, if the JIT functionality is the focus, verifying the `BPF_JIT` config is essential to reproducing and testing the reported issues, or confirming performance gains.

{
  "Expression": "config BPF_JIT"
}

{
  "Output": "kernel/bpf/Kconfig=27=config BPF_SYSCALL\n--\nkernel/bpf/Kconfig-41-\nkernel/bpf/Kconfig:42:config BPF_JIT\nkernel/bpf/Kconfig-43-\tbool \"Enable BPF Just In Time compiler\"\n--\nkernel/bpf/Kconfig-57-\nkernel/bpf/Kconfig:58:config BPF_JIT_ALWAYS_ON\nkernel/bpf/Kconfig-59-\tbool \"Permanently enable BPF JIT and remove BPF interpreter\"\n--\nkernel/bpf/Kconfig-68-\nkernel/bpf/Kconfig:69:config BPF_JIT_DEFAULT_ON\nkernel/bpf/Kconfig-70-\tdef_bool ARCH_WANT_DEFAULT_BPF_JIT || BPF_JIT_ALWAYS_ON\n"
}

gemini-3.1-pro-preview

null

null

							input: 5838
							output: 129
							thoughts: 166
						

**My Assessment of the BPF Patch**

Okay, so looking at this patch, my initial thought is that `BPF_JIT` is definitely a key factor here. The core of the change lies within `bpf_do_misc_fixups` and `__bpf_prog_select_runtime`. These are critical functions involved in the very process of loading and verifying BPF programs.

Given the nature of the change – specifically, the added logic to handle cases where JIT compilation is either unavailable or fails, potentially leading to the rejection of programs that require it (like those with inlined helper calls) – this screams "fuzz me!" to me. This introduces a new code path with potentially subtle edge cases.

Therefore, `bpf_do_misc_fixups` and `__bpf_prog_select_runtime` are the immediate focus symbols I'd want to target during fuzzing. I'll need to make sure the fuzzing harness appropriately tests the program loading, verification, and JIT compilation aspects. I'll need to ensure the fuzzing environment enables `BPF_SYSCALL` and, of course, `BPF_JIT`. These configurations are essential for exercising this new logic.

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "bpf_do_misc_fixups",
    "__bpf_prog_select_runtime"
  ],
  "Reasoning": "The patch adds logic to reject BPF programs if they require JIT compilation (e.g., because the JIT inlines a helper call) but JIT is unavailable or fails. This is a functional change in the core BPF verifier/loader and should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "BPF_JIT"
  ],
  "FocusSymbols": [
    "bpf_do_misc_fixups",
    "__bpf_prog_select_runtime"
  ],
  "Reasoning": "The patch adds logic to reject BPF programs if they require JIT compilation (e.g., because the JIT inlines a helper call) but JIT is unavailable or fails. This is a functional change in the core BPF verifier/loader and should be fuzzed.",
  "WorthFuzzing": true
}