AI Trajectory

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "SYN_COOKIES"
  ],
  "FocusSymbols": [
    "bpf_tcp_check_syncookie",
    "bpf_tcp_gen_syncookie"
  ],
  "Reasoning": "The patch adds a check to prevent non-full sockets (like request or timewait sockets) from being passed to the bpf_tcp_check_syncookie and bpf_tcp_gen_syncookie BPF helpers, which could lead to invalid memory accesses. Fuzzing should focus on these helpers with various socket types.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 074ee222289f838758da7cd9a4c145172ea16e63\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Aug 2 13:33:31 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/core/filter.c b/net/core/filter.c\nindex b446aa8be5c37..afdcfdf41489f 100644\n--- a/net/core/filter.c\n+++ b/net/core/filter.c\n@@ -7678,6 +7678,9 @@ BPF_CALL_5(bpf_tcp_check_syncookie, struct sock *, sk, void *, iph, u32, iph_len\n \tif (unlikely(!sk || th_len \u003c sizeof(*th)))\n \t\treturn -EINVAL;\n \n+\tif (!sk_fullsock(sk))\n+\t\treturn -EINVAL;\n+\n \t/* sk_listener() allows TCP_NEW_SYN_RECV, which makes no sense here. */\n \tif (sk-\u003esk_protocol != IPPROTO_TCP || sk-\u003esk_state != TCP_LISTEN)\n \t\treturn -EINVAL;\n@@ -7752,6 +7755,9 @@ BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,\n \tif (unlikely(!sk || th_len \u003c sizeof(*th) || th_len != th-\u003edoff * 4))\n \t\treturn -EINVAL;\n \n+\tif (!sk_fullsock(sk))\n+\t\treturn -EINVAL;\n+\n \tif (sk-\u003esk_protocol != IPPROTO_TCP || sk-\u003esk_state != TCP_LISTEN)\n \t\treturn -EINVAL;\n \n"
}

best-expensive

null

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "SYN_COOKIES"
  ],
  "FocusSymbols": [
    "bpf_tcp_check_syncookie",
    "bpf_tcp_gen_syncookie"
  ],
  "Reasoning": "The patch adds a check to prevent non-full sockets (like request or timewait sockets) from being passed to the bpf_tcp_check_syncookie and bpf_tcp_gen_syncookie BPF helpers, which could lead to invalid memory accesses. Fuzzing should focus on these helpers with various socket types.",
  "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).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
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.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. 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 074ee222289f838758da7cd9a4c145172ea16e63
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 2 13:33:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/core/filter.c b/net/core/filter.c
index b446aa8be5c37..afdcfdf41489f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7678,6 +7678,9 @@ BPF_CALL_5(bpf_tcp_check_syncookie, struct sock *, sk, void *, iph, u32, iph_len
 	if (unlikely(!sk || th_len < sizeof(*th)))
 		return -EINVAL;
 
+	if (!sk_fullsock(sk))
+		return -EINVAL;
+
 	/* sk_listener() allows TCP_NEW_SYN_RECV, which makes no sense here. */
 	if (sk->sk_protocol != IPPROTO_TCP || sk->sk_state != TCP_LISTEN)
 		return -EINVAL;
@@ -7752,6 +7755,9 @@ BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
 	if (unlikely(!sk || th_len < sizeof(*th) || th_len != th->doff * 4))
 		return -EINVAL;
 
+	if (!sk_fullsock(sk))
+		return -EINVAL;
+
 	if (sk->sk_protocol != IPPROTO_TCP || sk->sk_state != TCP_LISTEN)
 		return -EINVAL;
 

gemini-3.1-pro-preview

null

null

							input: 2232
							output: 36
							thoughts: 102
						

**Analyzing a BPF Patch**

Okay, so this patch is touching `net/core/filter.c`. That immediately grabs my attention – filter code can get really complex. It looks like it's adding `!sk_fullsock(sk)` checks to `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie`. Right, those are BPF helpers, so that's a key detail. The obvious questions pop up: are these functions actually *reachable* in a typical configuration, and, if so, under what circumstances? What kernel configs are required for this to even take effect? I need to understand the execution path here.

My next step is clear: I need to quickly determine where these functions are called. Time to dive into the codebase and search for instances of `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie`. That should give me a better understanding of the context and impact of this change.

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

{
  "Output": "net/core/filter.c=7665=static const struct bpf_func_proto bpf_skb_ecn_set_ce_proto = {\n--\nnet/core/filter.c-7671-\nnet/core/filter.c:7672:BPF_CALL_5(bpf_tcp_check_syncookie, struct sock *, sk, void *, iph, u32, iph_len,\nnet/core/filter.c-7673-\t   struct tcphdr *, th, u32, th_len)\n--\nnet/core/filter.c-7735-\nnet/core/filter.c:7736:static const struct bpf_func_proto bpf_tcp_check_syncookie_proto = {\nnet/core/filter.c:7737:\t.func\t\t= bpf_tcp_check_syncookie,\nnet/core/filter.c-7738-\t.gpl_only\t= true,\n--\nnet/core/filter.c=8464=tc_cls_act_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)\n--\nnet/core/filter.c-8574-\tcase BPF_FUNC_tcp_check_syncookie:\nnet/core/filter.c:8575:\t\treturn \u0026bpf_tcp_check_syncookie_proto;\nnet/core/filter.c-8576-\tcase BPF_FUNC_skb_ecn_set_ce:\n--\nnet/core/filter.c=8601=xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)\n--\nnet/core/filter.c-8639-\tcase BPF_FUNC_tcp_check_syncookie:\nnet/core/filter.c:8640:\t\treturn \u0026bpf_tcp_check_syncookie_proto;\nnet/core/filter.c-8641-\tcase BPF_FUNC_tcp_gen_syncookie:\n"
}

gemini-3.1-pro-preview

null

null

							input: 3099
							output: 28
							thoughts: 166
						

**My Analysis of the BPF Helper Patch**

Okay, so I'm looking at this patch and my initial thought is, "Ah, it's tightening up the use of `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie`." These are the BPF helpers that work within the TC and XDP worlds, right? And the change is a sanity check – they are preventing the use of these helpers on non-full sockets, like request or timewait sockets, which makes perfect sense. Functionally, this is a good, targeted improvement.

Now, my expert brain immediately jumps to configuration. I want to make sure I know all the implications. I know `net/core/filter.c` is involved, and that is usually tied to `CONFIG_NET`. But these BPF helpers are *usually* governed by `CONFIG_BPF_SYSCALL` and `CONFIG_CGROUP_BPF`, or related configurations, so I need to verify that all the dependencies are correct.

Let me take a look at `net/core/Makefile` and confirm which configurations are truly necessary for this change to be effective.

{
  "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: 3657
							output: 37
							thoughts: 64
						

Here's my analysis of the situation:

**Investigating the `filter.o` Module's Dependencies**

Okay, so I know that `filter.o` gets built unconditionally when `CONFIG_NET` is set. That's straightforward enough. However, I'm thinking about `bpf_tcp_check_syncookie`. The name rings a bell, and I'm pretty sure it has some dependency on `CONFIG_SYN_COOKIES`. I need to verify that, because if `bpf_tcp_check_syncookie` isn't properly guarded, we could see some unexpected build artifacts or even runtime behavior. Time to delve into the code. I'll take a look at `net/core/filter.c`, specifically around line 7672. That's likely where the relevant code is. Let's see what's actually going on in that section.

{
  "File": "net/core/filter.c",
  "FirstLine": 7660,
  "LineCount": 100
}

{
  "Contents": "7660:\t\t}\n7661:\t\n7662:\t\treturn insn - insn_buf;\n7663:\t}\n7664:\t\n7665:\tstatic const struct bpf_func_proto bpf_skb_ecn_set_ce_proto = {\n7666:\t\t.func           = bpf_skb_ecn_set_ce,\n7667:\t\t.gpl_only       = false,\n7668:\t\t.ret_type       = RET_INTEGER,\n7669:\t\t.arg1_type      = ARG_PTR_TO_CTX,\n7670:\t};\n7671:\t\n7672:\tBPF_CALL_5(bpf_tcp_check_syncookie, struct sock *, sk, void *, iph, u32, iph_len,\n7673:\t\t   struct tcphdr *, th, u32, th_len)\n7674:\t{\n7675:\t#ifdef CONFIG_SYN_COOKIES\n7676:\t\tint ret;\n7677:\t\n7678:\t\tif (unlikely(!sk || th_len \u003c sizeof(*th)))\n7679:\t\t\treturn -EINVAL;\n7680:\t\n7681:\t\tif (!sk_fullsock(sk))\n7682:\t\t\treturn -EINVAL;\n7683:\t\n7684:\t\t/* sk_listener() allows TCP_NEW_SYN_RECV, which makes no sense here. */\n7685:\t\tif (sk-\u003esk_protocol != IPPROTO_TCP || sk-\u003esk_state != TCP_LISTEN)\n7686:\t\t\treturn -EINVAL;\n7687:\t\n7688:\t\tif (!READ_ONCE(sock_net(sk)-\u003eipv4.sysctl_tcp_syncookies))\n7689:\t\t\treturn -EINVAL;\n7690:\t\n7691:\t\tif (!th-\u003eack || th-\u003erst || th-\u003esyn)\n7692:\t\t\treturn -ENOENT;\n7693:\t\n7694:\t\tif (unlikely(iph_len \u003c sizeof(struct iphdr)))\n7695:\t\t\treturn -EINVAL;\n7696:\t\n7697:\t\tif (tcp_synq_no_recent_overflow(sk))\n7698:\t\t\treturn -ENOENT;\n7699:\t\n7700:\t\t/* Both struct iphdr and struct ipv6hdr have the version field at the\n7701:\t\t * same offset so we can cast to the shorter header (struct iphdr).\n7702:\t\t */\n7703:\t\tswitch (((struct iphdr *)iph)-\u003eversion) {\n7704:\t\tcase 4:\n7705:\t\t\tif (sk-\u003esk_family == AF_INET6 \u0026\u0026 ipv6_only_sock(sk))\n7706:\t\t\t\treturn -EINVAL;\n7707:\t\n7708:\t\t\tret = __cookie_v4_check((struct iphdr *)iph, th);\n7709:\t\t\tbreak;\n7710:\t\n7711:\t#if IS_ENABLED(CONFIG_IPV6)\n7712:\t\tcase 6:\n7713:\t\t\tif (unlikely(iph_len \u003c sizeof(struct ipv6hdr)))\n7714:\t\t\t\treturn -EINVAL;\n7715:\t\n7716:\t\t\tif (sk-\u003esk_family != AF_INET6)\n7717:\t\t\t\treturn -EINVAL;\n7718:\t\n7719:\t\t\tret = __cookie_v6_check((struct ipv6hdr *)iph, th);\n7720:\t\t\tbreak;\n7721:\t#endif /* CONFIG_IPV6 */\n7722:\t\n7723:\t\tdefault:\n7724:\t\t\treturn -EPROTONOSUPPORT;\n7725:\t\t}\n7726:\t\n7727:\t\tif (ret \u003e 0)\n7728:\t\t\treturn 0;\n7729:\t\n7730:\t\treturn -ENOENT;\n7731:\t#else\n7732:\t\treturn -ENOTSUPP;\n7733:\t#endif\n7734:\t}\n7735:\t\n7736:\tstatic const struct bpf_func_proto bpf_tcp_check_syncookie_proto = {\n7737:\t\t.func\t\t= bpf_tcp_check_syncookie,\n7738:\t\t.gpl_only\t= true,\n7739:\t\t.pkt_access\t= true,\n7740:\t\t.ret_type\t= RET_INTEGER,\n7741:\t\t.arg1_type\t= ARG_PTR_TO_BTF_ID_SOCK_COMMON,\n7742:\t\t.arg2_type\t= ARG_PTR_TO_MEM | MEM_RDONLY,\n7743:\t\t.arg3_type\t= ARG_CONST_SIZE,\n7744:\t\t.arg4_type\t= ARG_PTR_TO_MEM | MEM_RDONLY,\n7745:\t\t.arg5_type\t= ARG_CONST_SIZE,\n7746:\t};\n7747:\t\n7748:\tBPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,\n7749:\t\t   struct tcphdr *, th, u32, th_len)\n7750:\t{\n7751:\t#ifdef CONFIG_SYN_COOKIES\n7752:\t\tu32 cookie;\n7753:\t\tu16 mss;\n7754:\t\n7755:\t\tif (unlikely(!sk || th_len \u003c sizeof(*th) || th_len != th-\u003edoff * 4))\n7756:\t\t\treturn -EINVAL;\n7757:\t\n7758:\t\tif (!sk_fullsock(sk))\n7759:\t\t\treturn -EINVAL;\n"
}

gemini-3.1-pro-preview

null

null

							input: 5468
							output: 32
							thoughts: 261
						

**My Assessment of the Patch**

Okay, so this is about integrating BPF with TCP syncookies. I see we definitely need `CONFIG_SYN_COOKIES` enabled, that's a given. And since we're using BPF, naturally, `CONFIG_BPF_SYSCALL` is required as well. The core functions here are `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie` – these are the BPF helpers that we're dealing with. They're designed to be called from within BPF programs, which makes sense.

The crucial part of this patch is the addition of the `!sk_fullsock(sk)` check. This is important: it prevents the helpers from being called with sockets that aren't fully established, like request sockets or those in the TIME-WAIT state. That's a solid defensive measure because trying to access fields on these non-full sockets that aren't guaranteed to exist could lead to a crash or other undesirable behavior. It's a classic example of a potential null-pointer dereference or similar issue.

To verify this patch, I'd need to craft a BPF program that intentionally calls either `bpf_tcp_check_syncookie` or `bpf_tcp_gen_syncookie` with a non-full socket as an argument. I will also have to make sure to enable the correct configs which are `CONFIG_BPF_SYSCALL`, `CONFIG_SYN_COOKIES` and `CONFIG_NET`. I should quickly double-check that `CONFIG_SYN_COOKIES` is the *exact* name and not something similar.

{
  "Expression": "config SYN_COOKIES",
  "PathPrefix": "net/ipv4/Kconfig"
}

{
  "Output": "net/ipv4/Kconfig=259=config IP_PIMSM_V2\n--\nnet/ipv4/Kconfig-267-\nnet/ipv4/Kconfig:268:config SYN_COOKIES\nnet/ipv4/Kconfig-269-\tbool \"IP: TCP syncookie support\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 6206
							output: 36
							thoughts: 152
						

**Analyzing Kernel Configuration Options**

Okay, definitely `SYN_COOKIES`, that's what we're after. Now, let's see what else might be connected to this. The function prototypes, `tc_cls_act_func_proto` and `xdp_func_proto`, are where the helpers are exposed. Hmm, so `CONFIG_NET_CLS_ACT` and `CONFIG_XDP_SOCKETS` could be indirectly relevant. But really, the crucial one here is likely `CONFIG_BPF_SYSCALL`.

Hold on... I need to double-check something. Is `tc_cls_act_func_proto` compiled *conditionally* on `CONFIG_NET_CLS_BPF` or `CONFIG_BPF_SYSCALL`? That sounds right. Just to be absolutely sure, let me jump into `net/core/filter.c` and confirm how `tc_cls_act_func_proto` is actually defined in relation to those other configs. I want to see the conditional compilation in context.

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

{
  "Output": "net/core/filter.c=8463=static const struct bpf_func_proto *\nnet/core/filter.c:8464:tc_cls_act_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)\nnet/core/filter.c-8465-{\n--\nnet/core/filter.c=11346=const struct bpf_verifier_ops tc_cls_act_verifier_ops = {\nnet/core/filter.c:11347:\t.get_func_proto\t\t= tc_cls_act_func_proto,\nnet/core/filter.c-11348-\t.is_valid_access\t= tc_cls_act_is_valid_access,\n"
}

gemini-3.1-pro-preview

null

null

							input: 6820
							output: 138
							thoughts: 269
						

**My Assessment of the Patch**

Okay, so I'm looking at this patch and immediately, I recognize that `tc_cls_act_verifier_ops` is relevant here, specifically for `BPF_PROG_TYPE_SCHED_CLS` and `BPF_PROG_TYPE_SCHED_ACT`. Right, those are the eBPF program types that are relevant to this work, and they're only available if `CONFIG_BPF_SYSCALL` is enabled. Makes sense. And since we are dealing with syncookies, `SYN_COOKIES` is another key config to keep in mind.

The core issue seems to be around `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie`. The patch's reasoning is clear; it’s a functional fix, preventing a crash or memory corruption when a *non-full* socket – like a request or TIME_WAIT socket – is erroneously passed to these BPF helpers. This is a classic vulnerability vector, easy to miss. This patch appears to be doing exactly what I would expect in this situation, adding a check to avoid the issue altogether.

The patch's impact is significant. Given the potential for crashes and memory errors, fuzzing this area is critical. We need to throw a variety of socket types at those helpers, especially the non-full ones mentioned, and verify that the fix is robust. This is definitely worth pursuing with a fuzzing campaign.

So, to summarize: the relevant configs are `BPF_SYSCALL` and `SYN_COOKIES`. The key functions to investigate are `bpf_tcp_check_syncookie` and `bpf_tcp_gen_syncookie`. Let's get fuzzing!

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "SYN_COOKIES"
  ],
  "FocusSymbols": [
    "bpf_tcp_check_syncookie",
    "bpf_tcp_gen_syncookie"
  ],
  "Reasoning": "The patch adds a check to prevent non-full sockets (like request or timewait sockets) from being passed to the bpf_tcp_check_syncookie and bpf_tcp_gen_syncookie BPF helpers, which could lead to invalid memory accesses. Fuzzing should focus on these helpers with various socket types.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BPF_SYSCALL",
    "SYN_COOKIES"
  ],
  "FocusSymbols": [
    "bpf_tcp_check_syncookie",
    "bpf_tcp_gen_syncookie"
  ],
  "Reasoning": "The patch adds a check to prevent non-full sockets (like request or timewait sockets) from being passed to the bpf_tcp_check_syncookie and bpf_tcp_gen_syncookie BPF helpers, which could lead to invalid memory accesses. Fuzzing should focus on these helpers with various socket types.",
  "WorthFuzzing": true
}