AI Trajectory

null

{
  "EnableConfigs": [
    "IPV6"
  ],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the core TCP receive path for both IPv4 and IPv6 to drop packets when a TIME-WAIT socket receives a packet and the listener's request queue is full. This is a functional change that should be fuzzed, but the modified functions are hot-path, so no specific FocusSymbols are provided.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit d56816381424e189fa49ed8d0938ff0bee0debb3\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Jul 12 15:13:22 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c\nindex 209ef7522508fc..ddb5daede802d3 100644\n--- a/net/ipv4/tcp_ipv4.c\n+++ b/net/ipv4/tcp_ipv4.c\n@@ -2310,6 +2310,14 @@ int tcp_v4_rcv(struct sk_buff *skb)\n \t\t\t\t\t\t\tinet_iif(skb),\n \t\t\t\t\t\t\tsdif);\n \t\tif (sk2) {\n+\t\t\tif (inet_csk_reqsk_queue_is_full(sk2)) {\n+\t\t\t\tdrop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;\n+\t\t\t\t__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);\n+\t\t\t\ttcp_listendrop(sk2);\n+\t\t\t\tinet_twsk_put(inet_twsk(sk));\n+\t\t\t\tgoto discard_it;\n+\t\t\t}\n+\n \t\t\tinet_twsk_deschedule_put(inet_twsk(sk));\n \t\t\tsk = sk2;\n \t\t\ttcp_v4_restore_cb(skb);\ndiff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c\nindex ebe161d72fbd07..8d3ff7184d03f5 100644\n--- a/net/ipv6/tcp_ipv6.c\n+++ b/net/ipv6/tcp_ipv6.c\n@@ -1969,6 +1969,15 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)\n \t\t\t\t\t    sdif);\n \t\tif (sk2) {\n \t\t\tstruct inet_timewait_sock *tw = inet_twsk(sk);\n+\n+\t\t\tif (inet_csk_reqsk_queue_is_full(sk2)) {\n+\t\t\t\tdrop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;\n+\t\t\t\t__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);\n+\t\t\t\ttcp_listendrop(sk2);\n+\t\t\t\tinet_twsk_put(tw);\n+\t\t\t\tgoto discard_it;\n+\t\t\t}\n+\n \t\t\tinet_twsk_deschedule_put(tw);\n \t\t\tsk = sk2;\n \t\t\ttcp_v6_restore_cb(skb);\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "IPV6"
  ],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the core TCP receive path for both IPv4 and IPv6 to drop packets when a TIME-WAIT socket receives a packet and the listener's request queue is full. This is a functional change that should be fuzzed, but the modified functions are hot-path, so no specific FocusSymbols are provided.",
  "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 d56816381424e189fa49ed8d0938ff0bee0debb3
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Jul 12 15:13:22 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 209ef7522508fc..ddb5daede802d3 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2310,6 +2310,14 @@ int tcp_v4_rcv(struct sk_buff *skb)
 							inet_iif(skb),
 							sdif);
 		if (sk2) {
+			if (inet_csk_reqsk_queue_is_full(sk2)) {
+				drop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;
+				__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);
+				tcp_listendrop(sk2);
+				inet_twsk_put(inet_twsk(sk));
+				goto discard_it;
+			}
+
 			inet_twsk_deschedule_put(inet_twsk(sk));
 			sk = sk2;
 			tcp_v4_restore_cb(skb);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index ebe161d72fbd07..8d3ff7184d03f5 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1969,6 +1969,15 @@ INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)
 					    sdif);
 		if (sk2) {
 			struct inet_timewait_sock *tw = inet_twsk(sk);
+
+			if (inet_csk_reqsk_queue_is_full(sk2)) {
+				drop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;
+				__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);
+				tcp_listendrop(sk2);
+				inet_twsk_put(tw);
+				goto discard_it;
+			}
+
 			inet_twsk_deschedule_put(tw);
 			sk = sk2;
 			tcp_v6_restore_cb(skb);

gemini-3.1-pro-preview

null

null

							input: 2247
							output: 27
							thoughts: 859
						

**Analyzing the TCP Time-Wait Listener Overflow Patch**

Okay, so I'm looking at this patch that introduces a specific check within the TCP receive path, impacting both IPv4 and IPv6. The core of it revolves around a scenario where a SYN packet arrives for a connection that's currently in TIME-WAIT state, but a listener socket is available, and, crucially, the listener's request queue is *full*. The patch adds the condition check `if (inet_csk_reqsk_queue_is_full(sk2))`. If that is true, then the patch now drops the packet with the `SKB_DROP_REASON_TCP_LISTEN_OVERFLOW` reason, increments a statistic, calls `tcp_listendrop(sk2)`, de-schedules the time-wait socket, and then goes to `discard_it`.

My immediate thought is, this is definitely something that merits some serious fuzzing. The functional change specifically targets how TIME-WAIT sockets interact with listeners when the listener's backlog is exhausted. This has the potential to expose subtle race conditions or unexpected behavior under heavy load.

Now, let's consider how we'd approach this with fuzzing. The patch modifies `tcp_v4_rcv` and `tcp_v6_rcv`, the main entry points for the IPv4 and IPv6 TCP receive paths, respectively. These are *extremely* hot path functions. The question now is whether we should explicitly list these in `FocusSymbols`. Normally, I wouldn't, as the prompt directs us to "Avoid listing generic hot-path functions to prevent skewed test distributions". However, in this case, the *specific* added logic is triggered when the TIME-WAIT socket interacts with a listener socket. Maybe we *should* list these functions to give fuzzing a hint? But no, these are very generic functions and we don't want to skew the fuzzer.

The more interesting, and likely more relevant, function is `inet_csk_reqsk_queue_is_full`. This is an inline function, so whether it warrants being listed depends on how the fuzzer handles inlines. Then there's `tcp_listendrop`, but that's probably also an inline helper, or small enough that we don't need to specify it.

Considering configurations, IPv4 and IPv6 TCP are pretty much always enabled. So, we're good there. `CONFIG_IPV6` is, of course, needed for IPv6. I should also check the source for `tcp_listendrop` and `inet_csk_reqsk_queue_is_full` to get a better sense of how they are used. Overall, I think this could be a good area to focus the fuzzer.

{
  "Expression": "inet_csk_reqsk_queue_is_full"
}

{
  "Output": "include/net/inet_connection_sock.h=285=static inline int inet_csk_reqsk_queue_len(const struct sock *sk)\n--\ninclude/net/inet_connection_sock.h-289-\ninclude/net/inet_connection_sock.h:290:static inline int inet_csk_reqsk_queue_is_full(const struct sock *sk)\ninclude/net/inet_connection_sock.h-291-{\n--\nnet/ipv4/tcp_input.c=7564=u16 tcp_get_syncookie_mss(struct request_sock_ops *rsk_ops,\n--\nnet/ipv4/tcp_input.c-7571-\tif (READ_ONCE(sock_net(sk)-\u003eipv4.sysctl_tcp_syncookies) != 2 \u0026\u0026\nnet/ipv4/tcp_input.c:7572:\t    !inet_csk_reqsk_queue_is_full(sk))\nnet/ipv4/tcp_input.c-7573-\t\treturn 0;\n--\nnet/ipv4/tcp_input.c=7590=int tcp_conn_request(struct request_sock_ops *rsk_ops,\n--\nnet/ipv4/tcp_input.c-7617-\nnet/ipv4/tcp_input.c:7618:\t\tif (syncookies == 2 || inet_csk_reqsk_queue_is_full(sk)) {\nnet/ipv4/tcp_input.c-7619-\t\t\twant_cookie = tcp_syn_flood_action(sk,\n--\nnet/ipv4/tcp_ipv4.c=2067=int tcp_v4_rcv(struct sk_buff *skb)\n--\nnet/ipv4/tcp_ipv4.c-2312-\t\tif (sk2) {\nnet/ipv4/tcp_ipv4.c:2313:\t\t\tif (inet_csk_reqsk_queue_is_full(sk2)) {\nnet/ipv4/tcp_ipv4.c-2314-\t\t\t\tdrop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;\n--\nnet/ipv6/tcp_ipv6.c=1728=INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)\n--\nnet/ipv6/tcp_ipv6.c-1972-\nnet/ipv6/tcp_ipv6.c:1973:\t\t\tif (inet_csk_reqsk_queue_is_full(sk2)) {\nnet/ipv6/tcp_ipv6.c-1974-\t\t\t\tdrop_reason = SKB_DROP_REASON_TCP_LISTEN_OVERFLOW;\n"
}

gemini-3.1-pro-preview

null

null

							input: 4412
							output: 19
							thoughts: 288
						

**My Assessment of the Patch's Fuzzing Implications**

Okay, so this patch introduces a check in the TCP receive path. Specifically, it's about dropping packets when a TIME-WAIT socket gets a packet and the listener's request queue is maxed out. Functionally, this is a pretty significant change to the core TCP receive mechanism, and that makes it a prime candidate for fuzzing.

My first instinct was to include `tcp_v4_rcv` and `tcp_v6_rcv` in the `FocusSymbols` list, but since these are *hot-path* functions, listing them is probably going to be more noise than signal. We don't want to specify hot-paths in the FocusSymbols as they'll likely already be covered. Plus, the diff only mentions those two and no other functions, so it simplifies the picture.

The config requirements are straightforward: basic networking support and `IPV6` for the IPv6 component. Since TCP itself is, as expected, always enabled, there are no other configurations needed. So, my approach will be to return `WorthFuzzing=true`. I will leave `FocusSymbols` empty, since the key functions are hot-path. Finally, I will specify `IPV6` in `EnableConfigs`.

Just to be absolutely sure, it might be worth double-checking for a more specific function we might be able to target. Oh, wait, the patch *does* modify `tcp_v4_rcv` and `tcp_v6_rcv`. They are hot-path functions, so leaving `FocusSymbols` empty is definitely the right approach.

Given the potential for fuzzing benefits here, let's also take a quick look at `tcp_listendrop` to make sure we haven't missed anything.

{
  "Expression": "tcp_listendrop"
}

{
  "Output": "include/net/tcp.h=2765=static inline void tcp_segs_in(struct tcp_sock *tp, const struct sk_buff *skb)\n--\ninclude/net/tcp.h-2785- */\ninclude/net/tcp.h:2786:static inline void tcp_listendrop(const struct sock *sk)\ninclude/net/tcp.h-2787-{\n--\nnet/ipv4/tcp_input.c=7590=int tcp_conn_request(struct request_sock_ops *rsk_ops,\n--\nnet/ipv4/tcp_input.c-7772-drop:\nnet/ipv4/tcp_input.c:7773:\ttcp_listendrop(sk);\nnet/ipv4/tcp_input.c-7774-\treturn 0;\n--\nnet/ipv4/tcp_ipv4.c=414=void tcp_req_err(struct sock *sk, u32 seq, bool abort)\n--\nnet/ipv4/tcp_ipv4.c-431-\t\tinet_csk_reqsk_queue_drop(req-\u003ersk_listener, req);\nnet/ipv4/tcp_ipv4.c:432:\t\ttcp_listendrop(req-\u003ersk_listener);\nnet/ipv4/tcp_ipv4.c-433-\t}\n--\nnet/ipv4/tcp_ipv4.c=1652=int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv4/tcp_ipv4.c-1661-drop:\nnet/ipv4/tcp_ipv4.c:1662:\ttcp_listendrop(sk);\nnet/ipv4/tcp_ipv4.c-1663-\treturn 0;\n--\nnet/ipv4/tcp_ipv4.c=1671=struct sock *tcp_v4_syn_recv_sock(const struct sock *sk, struct sk_buff *skb,\n--\nnet/ipv4/tcp_ipv4.c-1781-exit:\nnet/ipv4/tcp_ipv4.c:1782:\ttcp_listendrop(sk);\nnet/ipv4/tcp_ipv4.c-1783-\treturn NULL;\n--\nnet/ipv4/tcp_ipv4.c=2067=int tcp_v4_rcv(struct sk_buff *skb)\n--\nnet/ipv4/tcp_ipv4.c-2315-\t\t\t\t__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);\nnet/ipv4/tcp_ipv4.c:2316:\t\t\t\ttcp_listendrop(sk2);\nnet/ipv4/tcp_ipv4.c-2317-\t\t\t\tinet_twsk_put(inet_twsk(sk));\n--\nnet/ipv6/tcp_ipv6.c=1314=static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)\n--\nnet/ipv6/tcp_ipv6.c-1330-drop:\nnet/ipv6/tcp_ipv6.c:1331:\ttcp_listendrop(sk);\nnet/ipv6/tcp_ipv6.c-1332-\treturn 0; /* don't send reset */\n--\nnet/ipv6/tcp_ipv6.c=1380=static struct sock *tcp_v6_syn_recv_sock(const struct sock *sk, struct sk_buff *skb,\n--\nnet/ipv6/tcp_ipv6.c-1545-exit:\nnet/ipv6/tcp_ipv6.c:1546:\ttcp_listendrop(sk);\nnet/ipv6/tcp_ipv6.c-1547-\treturn NULL;\n--\nnet/ipv6/tcp_ipv6.c=1728=INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)\n--\nnet/ipv6/tcp_ipv6.c-1975-\t\t\t\t__NET_INC_STATS(net, LINUX_MIB_TCPREQQFULLDROP);\nnet/ipv6/tcp_ipv6.c:1976:\t\t\t\ttcp_listendrop(sk2);\nnet/ipv6/tcp_ipv6.c-1977-\t\t\t\tinet_twsk_put(tw);\n--\nnet/mptcp/subflow.c=674=static int subflow_v4_conn_request(struct sock *sk, struct sk_buff *skb)\n--\nnet/mptcp/subflow.c-687-drop:\nnet/mptcp/subflow.c:688:\ttcp_listendrop(sk);\nnet/mptcp/subflow.c-689-\treturn 0;\n--\nnet/mptcp/subflow.c=705=static int subflow_v6_conn_request(struct sock *sk, struct sk_buff *skb)\n--\nnet/mptcp/subflow.c-725-drop:\nnet/mptcp/subflow.c:726:\ttcp_listendrop(sk);\nnet/mptcp/subflow.c-727-\treturn 0; /* don't send reset */\n--\nnet/smc/af_smc.c=122=static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,\n--\nnet/smc/af_smc.c-167-\tdst_release(dst);\nnet/smc/af_smc.c:168:\ttcp_listendrop(sk);\nnet/smc/af_smc.c-169-\tif (smc)\n"
}

gemini-3.1-pro-preview

null

null

							input: 6547
							output: 101
							thoughts: 39
						

Okay, here's my take on those settings.

**Initial Considerations for Fuzzing Strategy**

Alright, so `tcp_listendrop` is an inline function – good to know. This suggests it's a critical component, likely called frequently and potentially vulnerable. Therefore, my immediate inclination is to flag it as "WorthFuzzing=true." It's definitely something I want to target for deeper exploration.

Next, I need to focus my fuzzing efforts. Since I don't have specific initial directions, I'm starting from a broader approach, so I'll begin with a blank slate, initializing `FocusSymbols=[]`. This gives me the flexibility to pinpoint areas of interest during the fuzzing process, based on observed behavior and any initial crashes. I'll dynamically refine this as I go.

Finally, I'll enable the "IPV6" configuration, setting `EnableConfigs=["IPV6"]`. IPV6 brings a whole different realm of possibilities. It introduces new data types and protocol behaviors that might expose vulnerabilities I wouldn't find otherwise. It's a key avenue to explore, given the potential complexity inherent in transitioning to IPv6. I'll make sure to note this configuration and its effects during the process.

{
  "EnableConfigs": [
    "IPV6"
  ],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the core TCP receive path for both IPv4 and IPv6 to drop packets when a TIME-WAIT socket receives a packet and the listener's request queue is full. This is a functional change that should be fuzzed, but the modified functions are hot-path, so no specific FocusSymbols are provided.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "IPV6"
  ],
  "FocusSymbols": [],
  "Reasoning": "The patch modifies the core TCP receive path for both IPv4 and IPv6 to drop packets when a TIME-WAIT socket receives a packet and the listener's request queue is full. This is a functional change that should be fuzzed, but the modified functions are hot-path, so no specific FocusSymbols are provided.",
  "WorthFuzzing": true
}