AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the TCP receive path by replacing a call to tcp_set_window_clamp with a direct WRITE_ONCE to tp-\u003ewindow_clamp in tcp_measure_rcv_mss. This avoids the additional logic in tcp_set_window_clamp (such as adjusting rcv_ssthresh) and is a functional change in core TCP logic.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 28f3c38e9421b8513ebc7eadec84494166a8c6c6\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Jul 26 12:12:42 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c\nindex daff93d5134287..5b6378b94701ef 100644\n--- a/net/ipv4/tcp_input.c\n+++ b/net/ipv4/tcp_input.c\n@@ -252,7 +252,7 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)\n \t\t\t\tstruct tcp_sock *tp = tcp_sk(sk);\n \n \t\t\t\tval = tcp_win_from_space(sk, sk-\u003esk_rcvbuf);\n-\t\t\t\ttcp_set_window_clamp(sk, val);\n+\t\t\t\tWRITE_ONCE(tp-\u003ewindow_clamp, val);\n \n \t\t\t\tif (tp-\u003ewindow_clamp \u003c tp-\u003ercvq_space.space)\n \t\t\t\t\ttp-\u003ercvq_space.space = tp-\u003ewindow_clamp;\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the TCP receive path by replacing a call to tcp_set_window_clamp with a direct WRITE_ONCE to tp-\u003ewindow_clamp in tcp_measure_rcv_mss. This avoids the additional logic in tcp_set_window_clamp (such as adjusting rcv_ssthresh) and is a functional change in core TCP logic.",
  "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 28f3c38e9421b8513ebc7eadec84494166a8c6c6
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Jul 26 12:12:42 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index daff93d5134287..5b6378b94701ef 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -252,7 +252,7 @@ static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)
 				struct tcp_sock *tp = tcp_sk(sk);
 
 				val = tcp_win_from_space(sk, sk->sk_rcvbuf);
-				tcp_set_window_clamp(sk, val);
+				WRITE_ONCE(tp->window_clamp, val);
 
 				if (tp->window_clamp < tp->rcvq_space.space)
 					tp->rcvq_space.space = tp->window_clamp;

gemini-3.1-pro-preview

null

null

							input: 2082
							output: 37
							thoughts: 73
						

**Analyzing a TCP Input Modification**

Okay, so I'm looking at this patch for `net/ipv4/tcp_input.c`. It seems they've made a pretty straightforward change, specifically within the `tcp_measure_rcv_mss` function. The original line, `tcp_set_window_clamp(sk, val);`, has been replaced with `WRITE_ONCE(tp->window_clamp, val);`.

My initial thought is to understand *why* this change was made. `tcp_set_window_clamp` is probably a function call, so I need to check its implementation and understand what it actually *does* in the context of receiving MSS and the window clamp. Knowing the specifics will provide the context for what this rewrite implies. Is this a performance optimization? A concurrency issue fix? Is `WRITE_ONCE` more efficient, or safer somehow?

I'll dive into the definition of `tcp_set_window_clamp` next. I want to see if this `WRITE_ONCE` replacement brings any performance benefits or potential for locking issues.

no matches

{
  "Expression": "tcp_set_window_clamp",
  "PathPrefix": "net/ipv4/tcp_input.c"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 2438
							output: 38
							thoughts: 31
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating a TCP Window Clamp Change**

Hmm, *wait a minute*. Did I just read that `tcp_set_window_clamp` was either removed entirely, or its behaviour substantially altered? That's a critical function for managing receive window sizing, and any change there needs immediate attention. I need to understand the implications of this.

Right, let’s get a handle on what might be going on, I should start by digging into the core logic. Specifically, I need to understand if the clamping behavior has just been moved elsewhere in the code. I'll need to look at what's directly connected to the receive window sizing. Ah, yes, `tcp_measure_rcv_mss`. If the clamp is gone, maybe the receive MSS logic is directly responsible for influencing the window size. I'll need to check the interactions between those two to fully understand the impact. This could be a significant change affecting performance and flow control, and I need to assess the modifications quickly.

{
  "Expression": "tcp_measure_rcv_mss",
  "PathPrefix": "net/ipv4/tcp_input.c"
}

{
  "Output": "net/ipv4/tcp_input.c-51- *\t\t\t\t\ta fatal error if it might still happen.\nnet/ipv4/tcp_input.c:52: *\t\tAndi Kleen:\t\tAdd tcp_measure_rcv_mss to make\nnet/ipv4/tcp_input.c-53- *\t\t\t\t\tconnections with MSS\u003cmin(MTU,ann. MSS)\n--\nnet/ipv4/tcp_input.c=211=static __cold void tcp_gro_dev_warn(const struct sock *sk, const struct sk_buff *skb,\n--\nnet/ipv4/tcp_input.c-226- */\nnet/ipv4/tcp_input.c:227:static void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)\nnet/ipv4/tcp_input.c-228-{\n--\nnet/ipv4/tcp_input.c=778=static void tcp_clamp_window(struct sock *sk)\n--\nnet/ipv4/tcp_input.c-803- * Overestimations make us ACKing less frequently than needed.\nnet/ipv4/tcp_input.c:804: * Underestimations are more easy to detect and fix by tcp_measure_rcv_mss().\nnet/ipv4/tcp_input.c-805- */\n--\nnet/ipv4/tcp_input.c=1015=static void tcp_event_data_recv(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/tcp_input.c-1022-\nnet/ipv4/tcp_input.c:1023:\ttcp_measure_rcv_mss(sk, skb);\nnet/ipv4/tcp_input.c-1024-\n--\nnet/ipv4/tcp_input.c=5381=static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/tcp_input.c-5398-\nnet/ipv4/tcp_input.c:5399:\ttcp_measure_rcv_mss(sk, skb);\nnet/ipv4/tcp_input.c-5400-\t/* Disable header prediction. */\n"
}

gemini-3.1-pro-preview

null

null

							input: 3301
							output: 27
							thoughts: 80
						

Okay, here's my take on those thoughts, framed as my own internal monologue:

**Analyzing the Window Clamp Modification**

Alright, so the commit's replaced a call to `tcp_set_window_clamp(sk, val)` with a `WRITE_ONCE(tp->window_clamp, val)`. Hmm, this is interesting. Immediately, I'm trying to figure out the reasoning. My first thought is: was `tcp_set_window_clamp` really a full-blown function, or was it a static inline function or even just a macro? Sometimes these changes are about performance, potentially removing a function call overhead. Other times, it's about memory ordering and synchronization.

I need to confirm the nature of `tcp_set_window_clamp` to understand the true impact of this change, so I'll check its definition. This will reveal the original implementation, and from there I can better reason about the implications of moving to `WRITE_ONCE`. Was there some implicit locking or memory barrier associated with the original function? Has this now been made explicit? I should look for potential race conditions. Is this potentially a critical change to the memory model?

{
  "Expression": "tcp_set_window_clamp",
  "PathPrefix": ""
}

{
  "Output": "include/net/tcp.h=516=void tcp_set_rcvbuf(struct sock *sk, int val);\ninclude/net/tcp.h:517:int tcp_set_window_clamp(struct sock *sk, int val);\ninclude/net/tcp.h-518-\n--\nnet/ipv4/tcp.c=1857=void tcp_set_rcvbuf(struct sock *sk, int val)\nnet/ipv4/tcp.c-1858-{\nnet/ipv4/tcp.c:1859:\ttcp_set_window_clamp(sk, tcp_win_from_space(sk, val));\nnet/ipv4/tcp.c-1860-}\n--\nnet/ipv4/tcp.c=3787=EXPORT_SYMBOL(tcp_sock_set_keepcnt);\nnet/ipv4/tcp.c-3788-\nnet/ipv4/tcp.c:3789:int tcp_set_window_clamp(struct sock *sk, int val)\nnet/ipv4/tcp.c-3790-{\n--\nnet/ipv4/tcp.c=3837=int do_tcp_setsockopt(struct sock *sk, int level, int optname,\n--\nnet/ipv4/tcp.c-4055-\tcase TCP_WINDOW_CLAMP:\nnet/ipv4/tcp.c:4056:\t\terr = tcp_set_window_clamp(sk, val);\nnet/ipv4/tcp.c-4057-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 4046
							output: 37
							thoughts: 71
						

Okay, let me break this down.

**Diving into `tcp_set_window_clamp`**

Hmm, so `tcp_set_window_clamp`... right, I see it's an *exported* function, or at least a function defined within `net/ipv4/tcp.c`. Okay, that's the first clue. But wait, this isn't *just* setting `tp->window_clamp`, is it? There's got to be more to it. I need to understand the function's full purpose. Time to dig in and see exactly what `tcp_set_window_clamp` is doing. I need to be sure I understand the complete impact and usage of that function.

{
  "File": "net/ipv4/tcp.c",
  "FirstLine": 3789,
  "LineCount": 20
}

{
  "Contents": "3789:\tint tcp_set_window_clamp(struct sock *sk, int val)\n3790:\t{\n3791:\t\tu32 old_window_clamp, new_window_clamp, new_rcv_ssthresh;\n3792:\t\tstruct tcp_sock *tp = tcp_sk(sk);\n3793:\t\n3794:\t\tif (!val) {\n3795:\t\t\tif (sk-\u003esk_state != TCP_CLOSE)\n3796:\t\t\t\treturn -EINVAL;\n3797:\t\t\tWRITE_ONCE(tp-\u003ewindow_clamp, 0);\n3798:\t\t\treturn 0;\n3799:\t\t}\n3800:\t\n3801:\t\told_window_clamp = tp-\u003ewindow_clamp;\n3802:\t\tnew_window_clamp = max_t(int, SOCK_MIN_RCVBUF / 2, val);\n3803:\t\n3804:\t\tif (new_window_clamp == old_window_clamp)\n3805:\t\t\treturn 0;\n3806:\t\n3807:\t\tWRITE_ONCE(tp-\u003ewindow_clamp, new_window_clamp);\n3808:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 4630
							output: 37
							thoughts: 316
						

**Analyzing the `tcp_set_window_clamp` Function**

Okay, so I'm looking at this `tcp_set_window_clamp` function and, wait a minute, it does more than I initially thought. It's not just a straightforward window clamp setter. It seems to have some extra logic embedded within it. I see that it checks for a zero value, and if it receives one *and* the socket state isn't `TCP_CLOSE`, it returns an error. Otherwise, it updates `tp->window_clamp` with either the minimum buffer size divided by two or the provided value, whichever is larger, after also writing the value with `WRITE_ONCE`.

Now, the patch is replacing this entire function call with a direct `WRITE_ONCE` write to `tp->window_clamp` in `tcp_measure_rcv_mss`. That's a little concerning... I wonder why. By doing that, the patch is bypassing all the additional checks and potentially the `rcv_ssthresh` and `sk_state` update.

I need to see the remaining parts of this function to fully understand the implications of this change. Is this a performance optimization, or is it going to cause some unexpected behavior? I need to analyze the surrounding code to determine if bypassing those extra checks is actually safe here.

{
  "File": "net/ipv4/tcp.c",
  "FirstLine": 3809,
  "LineCount": 20
}

{
  "Contents": "3809:\t\t/* Need to apply the reserved mem provisioning only\n3810:\t\t * when shrinking the window clamp.\n3811:\t\t */\n3812:\t\tif (new_window_clamp \u003c old_window_clamp) {\n3813:\t\t\t__tcp_adjust_rcv_ssthresh(sk, new_window_clamp);\n3814:\t\t} else {\n3815:\t\t\tnew_rcv_ssthresh = min(tp-\u003ercv_wnd, new_window_clamp);\n3816:\t\t\ttp-\u003ercv_ssthresh = max(new_rcv_ssthresh, tp-\u003ercv_ssthresh);\n3817:\t\t}\n3818:\t\treturn 0;\n3819:\t}\n3820:\t\n3821:\tint tcp_sock_set_maxseg(struct sock *sk, int val)\n3822:\t{\n3823:\t\t/* Values greater than interface MTU won't take effect. However\n3824:\t\t * at the point when this call is done we typically don't yet\n3825:\t\t * know which interface is going to be used\n3826:\t\t */\n3827:\t\tif (val \u0026\u0026 (val \u003c TCP_MIN_MSS || val \u003e MAX_TCP_WINDOW))\n3828:\t\t\treturn -EINVAL;\n"
}

gemini-3.1-pro-preview

null

null

							input: 5618
							output: 38
							thoughts: 143
						

**Analyzing a TCP Receive Path Patch**

Okay, so this patch is interesting. It looks like the original code was using `tcp_set_window_clamp`, which in turn calls `__tcp_adjust_rcv_ssthresh` and updates `rcv_ssthresh`. But, by swapping that out with `WRITE_ONCE(tp->window_clamp, val)`, the patch is bypassing the `rcv_ssthresh` update and that specific function call. This is definitely a functional change – it's altering how the TCP receive path behaves.

The key question is, does this warrant fuzzing? Absolutely, it does. Any change to the TCP receive window logic is a potential attack vector, or at the very least, a source of subtle performance differences. This is critical.

Now, a related thought popped up. I need to be sure. I'm recalling that `tcp_measure_rcv_mss` is involved when data is received. I should check how that fits into this picture. Time to dig into the `tcp_measure_rcv_mss` function. Let me see...

{
  "File": "net/ipv4/tcp_input.c",
  "FirstLine": 227,
  "LineCount": 40
}

{
  "Contents": " 227:\tstatic void tcp_measure_rcv_mss(struct sock *sk, const struct sk_buff *skb)\n 228:\t{\n 229:\t\tstruct inet_connection_sock *icsk = inet_csk(sk);\n 230:\t\tconst unsigned int lss = icsk-\u003eicsk_ack.last_seg_size;\n 231:\t\tunsigned int len;\n 232:\t\n 233:\t\ticsk-\u003eicsk_ack.last_seg_size = 0;\n 234:\t\n 235:\t\t/* skb-\u003elen may jitter because of SACKs, even if peer\n 236:\t\t * sends good full-sized frames.\n 237:\t\t */\n 238:\t\tlen = skb_shinfo(skb)-\u003egso_size ? : skb-\u003elen;\n 239:\t\tif (len \u003e= icsk-\u003eicsk_ack.rcv_mss) {\n 240:\t\t\t/* Note: divides are still a bit expensive.\n 241:\t\t\t * For the moment, only adjust scaling_ratio\n 242:\t\t\t * when we update icsk_ack.rcv_mss.\n 243:\t\t\t */\n 244:\t\t\tif (unlikely(len != icsk-\u003eicsk_ack.rcv_mss)) {\n 245:\t\t\t\tu64 val = (u64)skb-\u003elen \u003c\u003c TCP_RMEM_TO_WIN_SCALE;\n 246:\t\t\t\tu8 old_ratio = tcp_sk(sk)-\u003escaling_ratio;\n 247:\t\n 248:\t\t\t\tdo_div(val, skb-\u003etruesize);\n 249:\t\t\t\ttcp_sk(sk)-\u003escaling_ratio = val ? val : 1;\n 250:\t\n 251:\t\t\t\tif (old_ratio != tcp_sk(sk)-\u003escaling_ratio) {\n 252:\t\t\t\t\tstruct tcp_sock *tp = tcp_sk(sk);\n 253:\t\n 254:\t\t\t\t\tval = tcp_win_from_space(sk, sk-\u003esk_rcvbuf);\n 255:\t\t\t\t\tWRITE_ONCE(tp-\u003ewindow_clamp, val);\n 256:\t\n 257:\t\t\t\t\tif (tp-\u003ewindow_clamp \u003c tp-\u003ercvq_space.space)\n 258:\t\t\t\t\t\ttp-\u003ercvq_space.space = tp-\u003ewindow_clamp;\n 259:\t\t\t\t}\n 260:\t\t\t}\n 261:\t\t\ticsk-\u003eicsk_ack.rcv_mss = min_t(unsigned int, len,\n 262:\t\t\t\t\t\t       tcp_sk(sk)-\u003eadvmss);\n 263:\t\t\t/* Account for possibly-removed options */\n 264:\t\t\tDO_ONCE_LITE_IF(len \u003e icsk-\u003eicsk_ack.rcv_mss + MAX_TCP_OPTION_SPACE,\n 265:\t\t\t\t\ttcp_gro_dev_warn, sk, skb, len);\n 266:\t\t\t/* If the skb has a len of exactly 1*MSS and has the PSH bit\n"
}

gemini-3.1-pro-preview

null

null

							input: 6816
							output: 37
							thoughts: 260
						

**Analyzing a TCP Stack Patch**

Okay, so this patch is changing `tcp_set_window_clamp(sk, val)` to `WRITE_ONCE(tp->window_clamp, val)`. My immediate thought is, was `tcp_set_window_clamp` introduced recently, or was it modified? I need to understand if the original implementation had a flaw – perhaps a lockdep warning, a crash, or just a logic error in its use.

Digging deeper, I see that `tcp_set_window_clamp` calls `__tcp_adjust_rcv_ssthresh`, and that function *could* be doing something quite involved. This is definitely a functional change in the core TCP stack; we're not just talking about cosmetic code. And, critically, this is reachable through normal TCP data reception. That makes this WorthFuzzing=true in my book.

Now, as I'm thinking about fuzzing, the `FocusSymbols` section highlights that `tcp_measure_rcv_mss` is static. Hmm, let me check the call sites for it. Ah, `tcp_measure_rcv_mss` is called from `tcp_event_data_recv` and `tcp_data_queue_ofo`. Okay, and `tcp_event_data_recv` is called from `tcp_rcv_established`, `tcp_rcv_state_process`, and likely other places. Given its role as a key function in TCP data reception and the core nature of this change, I will definitely want to investigate `tcp_event_data_recv` further.

{
  "Expression": "tcp_event_data_recv",
  "PathPrefix": "net/ipv4/tcp_input.c"
}

{
  "Output": "net/ipv4/tcp_input.c=995=static void tcp_save_lrcv_flowlabel(struct sock *sk, const struct sk_buff *skb)\n--\nnet/ipv4/tcp_input.c-1014- */\nnet/ipv4/tcp_input.c:1015:static void tcp_event_data_recv(struct sock *sk, struct sk_buff *skb)\nnet/ipv4/tcp_input.c-1016-{\n--\nnet/ipv4/tcp_input.c=5607=static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/tcp_input.c-5671-\t\tif (skb-\u003elen)\nnet/ipv4/tcp_input.c:5672:\t\t\ttcp_event_data_recv(sk, skb);\nnet/ipv4/tcp_input.c-5673-\t\tif (TCP_SKB_CB(skb)-\u003etcp_flags \u0026 TCPHDR_FIN)\n--\nnet/ipv4/tcp_input.c=6500=void tcp_rcv_established(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/tcp_input.c-6637-\nnet/ipv4/tcp_input.c:6638:\t\t\ttcp_event_data_recv(sk, skb);\nnet/ipv4/tcp_input.c-6639-\n"
}

gemini-3.1-pro-preview

null

null

							input: 7830
							output: 107
							thoughts: 1032
						

**Analyzing the TCP Receive Path for Fuzzing Focus**

Okay, here's what I'm thinking. I need to figure out the right entry points or functions to highlight for fuzzing, given this patch's changes. The primary goal is to avoid listing functions that are overly generic or hot-path, because that'll skew the test distributions.

I'm starting with the entry points: `tcp_data_queue` and `tcp_rcv_established`. `tcp_data_queue` is called by `tcp_rcv_state_process`, and `tcp_rcv_established` is the fast path. The prompt steers me away from hot-paths, and `tcp_rcv_established` definitely fits that description. `tcp_data_queue`, though, is static. Hmm...

The patch is touching `tcp_measure_rcv_mss`, which calls `tcp_set_window_clamp`.  `tcp_measure_rcv_mss` is static. So, the question is whether there are relevant non-static functions involved.

`tcp_rcv_state_process` and `tcp_set_window_clamp` are both non-static. The patch touches the *call* to `tcp_set_window_clamp`, but isn't modifying that function directly. I've re-examined the code. The patch removes the call to `tcp_set_window_clamp` within `tcp_measure_rcv_mss`.

Let's look at the callers of `tcp_measure_rcv_mss`. We have `tcp_event_data_recv` and `tcp_data_queue_ofo`, both static.  Since the primary function under scrutiny (`tcp_measure_rcv_mss`) and its immediate callers are static, my instinct is to look elsewhere. But the non-static callers include `tcp_rcv_established` (hot-path) and `tcp_rcv_state_process` (also hot-path), and, I'm trying to avoid listing hot paths.

Could I just list `tcp_rcv_state_process` since the patch is touching the TCP receive path? But the prompt advises against this. Maybe leave `FocusSymbols` empty. The patch directly touches a static function, and if I don't list anything, the fuzzer might test `tcp_rcv_state_process` as well.

The patch changes the call to `tcp_set_window_clamp` and it seems the change is important, in which `tcp_set_window_clamp` is unnecessary.

Let's do one last check for non-static functions in this part of the code. Again, `tcp_data_queue`, `tcp_data_queue_ofo`, and `tcp_event_data_recv` are static.  The modified function is static (`tcp_measure_rcv_mss`).

So, I'm leaning toward leaving `FocusSymbols` empty. This should direct the fuzzer toward the most relevant code and avoid skewing it towards hot-path functions. Core TCP is always enabled, so no specific CONFIG options are needed. This is a functional change in TCP's core receive logic, worth testing.

{
  "EnableConfigs": [],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the TCP receive path by replacing a call to tcp_set_window_clamp with a direct WRITE_ONCE to tp-\u003ewindow_clamp in tcp_measure_rcv_mss. This avoids the additional logic in tcp_set_window_clamp (such as adjusting rcv_ssthresh) and is a functional change in core TCP logic.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": null,
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the TCP receive path by replacing a call to tcp_set_window_clamp with a direct WRITE_ONCE to tp-\u003ewindow_clamp in tcp_measure_rcv_mss. This avoids the additional logic in tcp_set_window_clamp (such as adjusting rcv_ssthresh) and is a functional change in core TCP logic.",
  "WorthFuzzing": true
}