AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sock_destroy"
  ],
  "Reasoning": "The patch adds a check to `bpf_sock_destroy` to ensure it is only called on full sockets, preventing potential crashes or unexpected behavior when called on request or timewait sockets. This is a functional change in a BPF kfunc that is reachable from BPF programs.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit fabaa1844c8a86e60539a3a2f7a25ca44b842ba3\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Thu Jul 2 23:26:18 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/core/filter.c b/net/core/filter.c\nindex 69ec1a4c0f9da1..a0fcafb08b9685 100644\n--- a/net/core/filter.c\n+++ b/net/core/filter.c\n@@ -12665,6 +12665,9 @@ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)\n {\n \tstruct sock *sk = (struct sock *)sock;\n \n+\tif (!sk_fullsock(sk))\n+\t\treturn -EOPNOTSUPP;\n+\n \t/* The locking semantics that allow for synchronous execution of the\n \t * destroy handlers are only supported for TCP and UDP.\n \t * Supporting protocols will need to acquire sock lock in the BPF context\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sock_destroy"
  ],
  "Reasoning": "The patch adds a check to `bpf_sock_destroy` to ensure it is only called on full sockets, preventing potential crashes or unexpected behavior when called on request or timewait sockets. This is a functional change in a BPF kfunc that is reachable from BPF programs.",
  "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 fabaa1844c8a86e60539a3a2f7a25ca44b842ba3
Author: syz-cluster <triage@syzkaller.com>
Date:   Thu Jul 2 23:26:18 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/filter.c b/net/core/filter.c
index 69ec1a4c0f9da1..a0fcafb08b9685 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -12665,6 +12665,9 @@ __bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)
 {
 	struct sock *sk = (struct sock *)sock;
 
+	if (!sk_fullsock(sk))
+		return -EOPNOTSUPP;
+
 	/* The locking semantics that allow for synchronous execution of the
 	 * destroy handlers are only supported for TCP and UDP.
 	 * Supporting protocols will need to acquire sock lock in the BPF context

gemini-3.1-pro-preview

null

null

							input: 1829
							output: 33
							thoughts: 77
						

Here's my analysis of the situation:

**Analyzing a Network Filter Patch**

Okay, so I'm looking at a patch that's making a change to `net/core/filter.c`, specifically impacting the `bpf_sock_destroy` function. My initial thought is to zero in on *why* this change is being made. The introduction of this `if (!sk_fullsock(sk)) return -EOPNOTSUPP;` check is immediately interesting. This suggests they're trying to restrict the behavior of `bpf_sock_destroy` based on the socket type.

Let me refresh my memory on what `bpf_sock_destroy` is *supposed* to do. It's likely involved in cleaning up BPF-related resources associated with a socket when the socket is closed or destroyed. The addition of `sk_fullsock` means we are now only handling certain kinds of sockets. The `sk_fullsock` macro probably indicates that we are dealing with a full socket, as opposed to a "half-open" or incomplete socket. The `-EOPNOTSUPP` error is clear; it indicates that the operation is not supported for that socket type. This is the crux of the patch; the developers have decided that `bpf_sock_destroy` isn't relevant or safe to operate on a certain set of sockets. So, my next step is to figure out the reasoning behind this decision. What types of sockets are *not* `fullsock`? That is what the patch is limiting.

{
  "Expression": "bpf_sock_destroy",
  "PathPrefix": "net/core/filter.c"
}

{
  "Output": "net/core/filter.c=12646=__bpf_kfunc_start_defs();\nnet/core/filter.c-12647-\nnet/core/filter.c:12648:/* bpf_sock_destroy: Destroy the given socket with ECONNABORTED error code.\nnet/core/filter.c-12649- *\n--\nnet/core/filter.c-12663- */\nnet/core/filter.c:12664:__bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)\nnet/core/filter.c-12665-{\n--\nnet/core/filter.c=12685=BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)\nnet/core/filter.c:12686:BTF_ID_FLAGS(func, bpf_sock_destroy)\nnet/core/filter.c-12687-BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)\n"
}

gemini-3.1-pro-preview

null

null

							input: 2543
							output: 28
							thoughts: 164
						

**Analyzing a BPF Kernel Function Modification**

Okay, so this patch is touching `bpf_sock_destroy`, specifically a BPF kfunc. That immediately piques my interest. The core change is the addition of this `if (!sk_fullsock(sk)) return -EOPNOTSUPP;` check. That’s a functional change, a pretty clear restriction being introduced. Given that this function is a BPF kfunc, meaning it's callable directly from BPF programs, this definitely warrants a closer look, especially for potential fuzzing targets.

My next thought is to identify any prerequisite configurations. I remember from experience that `net/core/filter.c` is involved here, and that gets compiled when `CONFIG_NET` is set, obviously. Then, BPF has to be enabled in order for BPF kfuncs to even *exist*. That's `CONFIG_BPF_SYSCALL`. I'll want to double-check `net/core/Makefile` to confirm the dependencies for `filter.c`, just to be certain. I want to make sure I'm testing in an environment that reflects the actual state of the kernel.

{
  "Expression": "filter.o",
  "PathPrefix": "net/core/Makefile"
}

{
  "Output": "net/core/Makefile=12=obj-y\t\t     += dev.o dev_api.o dev_addr_lists.o dst.o netevent.o \\\nnet/core/Makefile:13:\t\t\tneighbour.o rtnetlink.o utils.o link_watch.o filter.o \\\nnet/core/Makefile-14-\t\t\tsock_diag.o dev_ioctl.o tso.o sock_reuseport.o \\\n"
}

gemini-3.1-pro-preview

null

null

							input: 3096
							output: 33
							thoughts: 60
						

Okay, let's see what we've got here.

**Analyzing Build Dependencies and Function Definitions**

Alright, so `filter.o` is *always* built when `CONFIG_NET` is enabled. That's a given. Now, I'm trying to understand the definition of `bpf_sock_destroy`. The documentation says it's defined within `__bpf_kfunc_start_defs()`. My immediate thought is, are there any conditional preprocessor directives, `#ifdef`s, surrounding that function definition within that macro? Are we only seeing this function defined under specific compilation scenarios, or is it always present with the macro? I need to check for any conditional compilation that might affect the availability or behavior of that function. Let's dig deeper and see what that macro expansion reveals.

{
  "Expression": "bpf_sock_destroy",
  "PathPrefix": "net/core/filter.c"
}

{
  "Output": "net/core/filter.c=12646=__bpf_kfunc_start_defs();\nnet/core/filter.c-12647-\nnet/core/filter.c:12648:/* bpf_sock_destroy: Destroy the given socket with ECONNABORTED error code.\nnet/core/filter.c-12649- *\n--\nnet/core/filter.c-12663- */\nnet/core/filter.c:12664:__bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)\nnet/core/filter.c-12665-{\n--\nnet/core/filter.c=12685=BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)\nnet/core/filter.c:12686:BTF_ID_FLAGS(func, bpf_sock_destroy)\nnet/core/filter.c-12687-BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)\n"
}

gemini-3.1-pro-preview

null

null

							input: 3638
							output: 37
							thoughts: 22
						

Here's my summary, as though I'm reading and processing the provided information:

**Analyzing `net/core/filter.c` Around Line 12664**

Okay, let's dive into this. I'm going to pull up `net/core/filter.c` and zero in on roughly line 12664. I'm expecting something critical here, given that it's been specified with such precision. This likely indicates that the user is interested in a specific part of the code, maybe related to a known issue, a recent change, or a particular functionality. I'm anticipating that this section is either a potential bottleneck, a complex piece of logic, or perhaps an area where security vulnerabilities might be lurking. I'm ready to carefully parse the code around this line, looking for any immediate red flags or interesting design choices. Let's see what's being done... and determine the potential impact of that code.

{
  "File": "net/core/filter.c",
  "FirstLine": 12640,
  "LineCount": 50
}

{
  "Contents": "12640:\t\t\t\t\t\t       \u0026bpf_kfunc_set_sock_addr);\n12641:\t\tret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, \u0026bpf_kfunc_set_tcp_reqsk);\n12642:\t\treturn ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SOCK_OPS, \u0026bpf_kfunc_set_sock_ops);\n12643:\t}\n12644:\tlate_initcall(bpf_kfunc_init);\n12645:\t\n12646:\t__bpf_kfunc_start_defs();\n12647:\t\n12648:\t/* bpf_sock_destroy: Destroy the given socket with ECONNABORTED error code.\n12649:\t *\n12650:\t * The function expects a non-NULL pointer to a socket, and invokes the\n12651:\t * protocol specific socket destroy handlers.\n12652:\t *\n12653:\t * The helper can only be called from BPF contexts that have acquired the socket\n12654:\t * locks.\n12655:\t *\n12656:\t * Parameters:\n12657:\t * @sock: Pointer to socket to be destroyed\n12658:\t *\n12659:\t * Return:\n12660:\t * On error, may return EPROTONOSUPPORT, EINVAL.\n12661:\t * EPROTONOSUPPORT if protocol specific destroy handler is not supported.\n12662:\t * 0 otherwise\n12663:\t */\n12664:\t__bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)\n12665:\t{\n12666:\t\tstruct sock *sk = (struct sock *)sock;\n12667:\t\n12668:\t\tif (!sk_fullsock(sk))\n12669:\t\t\treturn -EOPNOTSUPP;\n12670:\t\n12671:\t\t/* The locking semantics that allow for synchronous execution of the\n12672:\t\t * destroy handlers are only supported for TCP and UDP.\n12673:\t\t * Supporting protocols will need to acquire sock lock in the BPF context\n12674:\t\t * prior to invoking this kfunc.\n12675:\t\t */\n12676:\t\tif (!sk-\u003esk_prot-\u003ediag_destroy || (sk-\u003esk_protocol != IPPROTO_TCP \u0026\u0026\n12677:\t\t\t\t\t\t   sk-\u003esk_protocol != IPPROTO_UDP))\n12678:\t\t\treturn -EOPNOTSUPP;\n12679:\t\n12680:\t\treturn sk-\u003esk_prot-\u003ediag_destroy(sk, ECONNABORTED);\n12681:\t}\n12682:\t\n12683:\t__bpf_kfunc_end_defs();\n12684:\t\n12685:\tBTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)\n12686:\tBTF_ID_FLAGS(func, bpf_sock_destroy)\n12687:\tBTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)\n12688:\t\n12689:\tstatic int tracing_iter_filter(const struct bpf_prog *prog, u32 kfunc_id)\n"
}

gemini-3.1-pro-preview

null

null

							input: 4804
							output: 38
							thoughts: 58
						

Okay, here's my interpretation of those thoughts, presented as my own mental process:

**Diving into `bpf_sock_destroy`**

Alright, so `bpf_sock_destroy` is flagged as a BPF kfunc. Interesting, so it's a kernel function accessible from a BPF program. My immediate thought is, "Where's it *registered*?" Knowing where a kfunc is defined and made available is key to understanding its context. Let's see... it's in `bpf_sk_iter_kfunc_ids`, got it. Now, that's just the *registration*, I need to figure out where that registration is *used*. I need to trace back from `bpf_sk_iter_kfunc_ids` and see what's actually making use of this `bpf_sock_destroy`. That'll be where the real action is. Time to dig in and find those call sites.

{
  "Expression": "bpf_sk_iter_kfunc_ids",
  "PathPrefix": "net/core/filter.c"
}

{
  "Output": "net/core/filter.c=12683=__bpf_kfunc_end_defs();\nnet/core/filter.c-12684-\nnet/core/filter.c:12685:BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)\nnet/core/filter.c-12686-BTF_ID_FLAGS(func, bpf_sock_destroy)\nnet/core/filter.c:12687:BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)\nnet/core/filter.c-12688-\nnet/core/filter.c=12689=static int tracing_iter_filter(const struct bpf_prog *prog, u32 kfunc_id)\nnet/core/filter.c-12690-{\nnet/core/filter.c:12691:\tif (btf_id_set8_contains(\u0026bpf_sk_iter_kfunc_ids, kfunc_id) \u0026\u0026\nnet/core/filter.c-12692-\t    prog-\u003eexpected_attach_type != BPF_TRACE_ITER)\n--\nnet/core/filter.c=12697=static const struct btf_kfunc_id_set bpf_sk_iter_kfunc_set = {\nnet/core/filter.c-12698-\t.owner = THIS_MODULE,\nnet/core/filter.c:12699:\t.set   = \u0026bpf_sk_iter_kfunc_ids,\nnet/core/filter.c-12700-\t.filter = tracing_iter_filter,\n"
}

gemini-3.1-pro-preview

null

null

							input: 5532
							output: 26
							thoughts: 183
						

**My Initial Assessment of the BPF Sock Destroy Patch**

Okay, so I'm looking at this patch and my initial thought is that it's focusing on `bpf_sock_destroy`, specifically how it interacts with the `BPF_TRACE_ITER` mechanism when dealing with sockets. The core of it seems to be adding a check: `if (!sk_fullsock(sk)) return -EOPNOTSUPP;`. I immediately see this as a functional change, a specific attempt to avoid calling `sk->sk_prot->diag_destroy` on non-full sockets. This makes sense; it's a defensive measure, likely to prevent some kind of crash or undefined behavior in the kernel.

Given this, my expert intuition tells me this *definitely* warrants fuzzing. The change is specific, focused, and has the potential to impact a variety of socket states. The fact that `bpf_sock_destroy` is reachable through BPF programs just increases the attack surface, in my mind.

My next step is to nail down the essential configurations that need to be in place. `BPF_SYSCALL` is pretty standard, but I want to make sure I'm explicitly including it. `CONFIG_NET` is likely a given, but I'll make sure it's present. The main focus is to confirm if `bpf_sock_destroy` itself might be behind any specific config flags that I'm overlooking.

{
  "Expression": "bpf_sock_destroy",
  "PathPrefix": ""
}

{
  "Output": "net/core/filter.c=12646=__bpf_kfunc_start_defs();\nnet/core/filter.c-12647-\nnet/core/filter.c:12648:/* bpf_sock_destroy: Destroy the given socket with ECONNABORTED error code.\nnet/core/filter.c-12649- *\n--\nnet/core/filter.c-12663- */\nnet/core/filter.c:12664:__bpf_kfunc int bpf_sock_destroy(struct sock_common *sock)\nnet/core/filter.c-12665-{\n--\nnet/core/filter.c=12685=BTF_KFUNCS_START(bpf_sk_iter_kfunc_ids)\nnet/core/filter.c:12686:BTF_ID_FLAGS(func, bpf_sock_destroy)\nnet/core/filter.c-12687-BTF_KFUNCS_END(bpf_sk_iter_kfunc_ids)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c=9=__be16 serv_port = 0;\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-10-\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c:11:int bpf_sock_destroy(struct sock_common *sk) __ksym;\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-12-\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c=49=int iter_tcp6_client(struct bpf_iter__tcp *ctx)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-67-\tif (sock_cookie == *val)\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c:68:\t\tbpf_sock_destroy(sk_common);\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-69-\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c=74=int iter_tcp6_server(struct bpf_iter__tcp *ctx)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-97-\tif (srcp == serv_port)\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c:98:\t\tbpf_sock_destroy(sk_common);\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-99-\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c=105=int iter_udp6_client(struct bpf_iter__udp *ctx)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-120-\tif (sock_cookie == *val)\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c:121:\t\tbpf_sock_destroy((struct sock_common *)sk);\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-122-\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c=127=int iter_udp6_server(struct bpf_iter__udp *ctx)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-139-\tif (srcp == serv_port)\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c:140:\t\tbpf_sock_destroy((struct sock_common *)sk);\ntools/testing/selftests/bpf/progs/sock_destroy_prog.c-141-\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c=9=char _license[] SEC(\"license\") = \"GPL\";\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c-10-\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c:11:int bpf_sock_destroy(struct sock_common *sk) __ksym;\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c-12-\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c=13=SEC(\"tp_btf/tcp_destroy_sock\")\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c:14:__failure __msg(\"calling kernel function bpf_sock_destroy is not allowed\")\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c-15-int BPF_PROG(trace_tcp_destroy_sock, struct sock *sk)\n--\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c-17-\t/* should not load */\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c:18:\tbpf_sock_destroy((struct sock_common *)sk);\ntools/testing/selftests/bpf/progs/sock_destroy_prog_fail.c-19-\n--\ntools/testing/selftests/bpf/progs/sock_iter_batch.c=76=int iter_tcp_destroy(struct bpf_iter__tcp *ctx)\n--\ntools/testing/selftests/bpf/progs/sock_iter_batch.c-87-\ntools/testing/selftests/bpf/progs/sock_iter_batch.c:88:\tbpf_sock_destroy(sk_common);\ntools/testing/selftests/bpf/progs/sock_iter_batch.c-89-\tbpf_seq_write(ctx-\u003emeta-\u003eseq, \u0026sock_cookie, sizeof(sock_cookie));\n"
}

gemini-3.1-pro-preview

null

null

							input: 7616
							output: 106
							thoughts: 233
						

**My Assessment of the `bpf_sock_destroy` Patch**

Okay, so I've been looking at this patch related to `bpf_sock_destroy`, which, as a BPF kfunc, is pretty interesting. First off, it's pretty clear that it relies on `CONFIG_BPF_SYSCALL` being enabled, which is standard for most BPF-related stuff. And it lives in `net/core/filter.c`, part of the `net` subsystem that's built with `CONFIG_NET`. No surprises there.

The core of the patch involves adding a check for `sk_fullsock(sk)` before calling `sk->sk_prot->diag_destroy`. This is a *functional* change, and it's a good one. It's addressing a potential crash or undefined behavior when `bpf_sock_destroy` is called on something like a request socket or a timewait socket, which aren't necessarily full sockets. That's a classic issue – handling resource management and lifecycle correctly in the network stack is always tricky.

Given that it is an important functional change, I am sure this would be good to fuzz, and I would want to ensure it is.

The relevant symbol is clearly `bpf_sock_destroy`. Beyond that, I need to check for any other dependencies, beyond `BPF_SYSCALL`, that must be enabled. I know `bpf_sock_destroy` is also available for use in `BPF_TRACE_ITER` programs, which makes sense. `BPF_TRACE_ITER` is itself linked to `CONFIG_BPF_SYSCALL`. I don't see any other config options that are needed, and I'm confident about that.

Now, let's nail down what the outcome should be.

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sock_destroy"
  ],
  "Reasoning": "The patch adds a check to `bpf_sock_destroy` to ensure it is only called on full sockets, preventing potential crashes or unexpected behavior when called on request or timewait sockets. This is a functional change in a BPF kfunc that is reachable from BPF programs.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL"
  ],
  "FocusSymbols": [
    "bpf_sock_destroy"
  ],
  "Reasoning": "The patch adds a check to `bpf_sock_destroy` to ensure it is only called on full sockets, preventing potential crashes or unexpected behavior when called on request or timewait sockets. This is a functional change in a BPF kfunc that is reachable from BPF programs.",
  "WorthFuzzing": true
}