AI Trajectory

null

{
  "EnableConfigs": [
    "INET",
    "MPTCP"
  ],
  "FocusSymbols": [
    "tcp_send_active_reset",
    "tcp_disconnect",
    "tcp_abort"
  ],
  "KMSANReasoning": "The patch removes the `gfp_t priority` argument from `tcp_send_active_reset()` and hardcodes `GFP_ATOMIC` for the SKB allocation and transmission. This is a simple refactoring of memory allocation flags and does not introduce any new data structures, modify buffer lengths, or alter initialization logic. There is no risk of exposing uninitialized memory to user space or using it in control flow. Standard KASAN and other bug detectors are perfectly adequate to catch any potential issues related to this change.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies the allocation flags for sending active TCP resets to always use GFP_ATOMIC, altering core TCP and MPTCP logic.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit ac2d12be99734465bcc567c8d446c6ed4909de79\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 25 03:33:34 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/include/net/tcp.h b/include/net/tcp.h\nindex 670c20876f265..436495ff2271d 100644\n--- a/include/net/tcp.h\n+++ b/include/net/tcp.h\n@@ -765,8 +765,7 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,\n void tcp_send_probe0(struct sock *);\n int tcp_write_wakeup(struct sock *, int mib);\n void tcp_send_fin(struct sock *sk);\n-void tcp_send_active_reset(struct sock *sk, gfp_t priority,\n-\t\t\t   enum sk_rst_reason reason);\n+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason);\n int tcp_send_synack(struct sock *);\n void tcp_push_one(struct sock *, unsigned int mss_now);\n void __tcp_send_ack(struct sock *sk, u32 rcv_nxt, u16 flags);\ndiff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c\nindex b4237d0e994d6..93d723d8c1098 100644\n--- a/net/ipv4/tcp.c\n+++ b/net/ipv4/tcp.c\n@@ -3182,8 +3182,7 @@ void __tcp_close(struct sock *sk, long timeout)\n \t\t/* Unread data was tossed, zap the connection. */\n \t\tNET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);\n \t\ttcp_set_state(sk, TCP_CLOSE);\n-\t\ttcp_send_active_reset(sk, sk-\u003esk_allocation,\n-\t\t\t\t      SK_RST_REASON_TCP_ABORT_ON_CLOSE);\n+\t\ttcp_send_active_reset(sk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);\n \t} else if (sock_flag(sk, SOCK_LINGER) \u0026\u0026 !sk-\u003esk_lingertime) {\n \t\t/* Check zero linger _after_ checking for unread data. */\n \t\tsk-\u003esk_prot-\u003edisconnect(sk, 0);\n@@ -3257,7 +3256,7 @@ void __tcp_close(struct sock *sk, long timeout)\n \t\tstruct tcp_sock *tp = tcp_sk(sk);\n \t\tif (READ_ONCE(tp-\u003elinger2) \u003c 0) {\n \t\t\ttcp_set_state(sk, TCP_CLOSE);\n-\t\t\ttcp_send_active_reset(sk, GFP_ATOMIC,\n+\t\t\ttcp_send_active_reset(sk,\n \t\t\t\t\t      SK_RST_REASON_TCP_ABORT_ON_LINGER);\n \t\t\t__NET_INC_STATS(sock_net(sk),\n \t\t\t\t\tLINUX_MIB_TCPABORTONLINGER);\n@@ -3276,7 +3275,7 @@ void __tcp_close(struct sock *sk, long timeout)\n \tif (sk-\u003esk_state != TCP_CLOSE) {\n \t\tif (tcp_check_oom(sk, 0)) {\n \t\t\ttcp_set_state(sk, TCP_CLOSE);\n-\t\t\ttcp_send_active_reset(sk, GFP_ATOMIC,\n+\t\t\ttcp_send_active_reset(sk,\n \t\t\t\t\t      SK_RST_REASON_TCP_ABORT_ON_MEMORY);\n \t\t\t__NET_INC_STATS(sock_net(sk),\n \t\t\t\t\tLINUX_MIB_TCPABORTONMEMORY);\n@@ -3377,14 +3376,14 @@ int tcp_disconnect(struct sock *sk, int flags)\n \t} else if (unlikely(tp-\u003erepair)) {\n \t\tWRITE_ONCE(sk-\u003esk_err, ECONNABORTED);\n \t} else if (tcp_need_reset(old_state)) {\n-\t\ttcp_send_active_reset(sk, gfp_any(), SK_RST_REASON_TCP_STATE);\n+\t\ttcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);\n \t\tWRITE_ONCE(sk-\u003esk_err, ECONNRESET);\n \t} else if (tp-\u003esnd_nxt != tp-\u003ewrite_seq \u0026\u0026\n \t\t   (1 \u003c\u003c old_state) \u0026 (TCPF_CLOSING | TCPF_LAST_ACK)) {\n \t\t/* The last check adjusts for discrepancy of Linux wrt. RFC\n \t\t * states\n \t\t */\n-\t\ttcp_send_active_reset(sk, gfp_any(),\n+\t\ttcp_send_active_reset(sk,\n \t\t\t\t      SK_RST_REASON_TCP_DISCONNECT_WITH_DATA);\n \t\tWRITE_ONCE(sk-\u003esk_err, ECONNRESET);\n \t} else if (old_state == TCP_SYN_SENT)\n@@ -5147,8 +5146,7 @@ int tcp_abort(struct sock *sk, int err)\n \tbh_lock_sock(sk);\n \n \tif (tcp_need_reset(sk-\u003esk_state))\n-\t\ttcp_send_active_reset(sk, GFP_ATOMIC,\n-\t\t\t\t      SK_RST_REASON_TCP_STATE);\n+\t\ttcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);\n \ttcp_done_with_error(sk, err);\n \n \tbh_unlock_sock(sk);\ndiff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c\nindex f2709d585edbd..19a799e5d5ce3 100644\n--- a/net/ipv4/tcp_output.c\n+++ b/net/ipv4/tcp_output.c\n@@ -3849,15 +3849,14 @@ void tcp_send_fin(struct sock *sk)\n  * was unread data in the receive queue.  This behavior is recommended\n  * by RFC 2525, section 2.17.  -DaveM\n  */\n-void tcp_send_active_reset(struct sock *sk, gfp_t priority,\n-\t\t\t   enum sk_rst_reason reason)\n+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason)\n {\n \tstruct sk_buff *skb;\n \n \tTCP_INC_STATS(sock_net(sk), TCP_MIB_OUTRSTS);\n \n \t/* NOTE: No TCP options attached and we never retransmit this. */\n-\tskb = alloc_skb(MAX_TCP_HEADER, priority);\n+\tskb = alloc_skb(MAX_TCP_HEADER, GFP_ATOMIC);\n \tif (!skb) {\n \t\tNET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);\n \t\treturn;\n@@ -3869,7 +3868,7 @@ void tcp_send_active_reset(struct sock *sk, gfp_t priority,\n \t\t\t     TCPHDR_ACK | TCPHDR_RST);\n \ttcp_mstamp_refresh(tcp_sk(sk));\n \t/* Send it off. */\n-\tif (tcp_transmit_skb(sk, skb, 0, priority))\n+\tif (tcp_transmit_skb(sk, skb, 0, GFP_ATOMIC))\n \t\tNET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);\n \n \t/* skb of trace_tcp_send_reset() keeps the skb that caused RST,\ndiff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c\nindex 1038e7ba9c2eb..e56eae4bc341e 100644\n--- a/net/ipv4/tcp_timer.c\n+++ b/net/ipv4/tcp_timer.c\n@@ -126,7 +126,7 @@ static int tcp_out_of_resources(struct sock *sk, bool do_reset)\n \t\t    (!tp-\u003esnd_wnd \u0026\u0026 !tp-\u003epackets_out))\n \t\t\tdo_reset = true;\n \t\tif (do_reset)\n-\t\t\ttcp_send_active_reset(sk, GFP_ATOMIC,\n+\t\t\ttcp_send_active_reset(sk,\n \t\t\t\t\t      SK_RST_REASON_TCP_ABORT_ON_MEMORY);\n \t\ttcp_done(sk);\n \t\t__NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONMEMORY);\n@@ -809,7 +809,7 @@ static void tcp_keepalive_timer(struct timer_list *t)\n \t\t\t\tgoto out;\n \t\t\t}\n \t\t}\n-\t\ttcp_send_active_reset(sk, GFP_ATOMIC, SK_RST_REASON_TCP_STATE);\n+\t\ttcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);\n \t\tgoto death;\n \t}\n \n@@ -836,7 +836,7 @@ static void tcp_keepalive_timer(struct timer_list *t)\n \t\t    icsk-\u003eicsk_probes_out \u003e 0) ||\n \t\t    (user_timeout == 0 \u0026\u0026\n \t\t    icsk-\u003eicsk_probes_out \u003e= keepalive_probes(tp))) {\n-\t\t\ttcp_send_active_reset(sk, GFP_ATOMIC,\n+\t\t\ttcp_send_active_reset(sk,\n \t\t\t\t\t      SK_RST_REASON_TCP_KEEPALIVE_TIMEOUT);\n \t\t\ttcp_write_err(sk);\n \t\t\tgoto out;\ndiff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c\nindex b474d03620a75..e1f08f71cdb16 100644\n--- a/net/mptcp/protocol.c\n+++ b/net/mptcp/protocol.c\n@@ -3109,8 +3109,7 @@ static void mptcp_do_fastclose(struct sock *sk)\n \t\t */\n \t\tinet_csk(ssk)-\u003eicsk_ack.rcv_mss = TCP_MIN_MSS;\n \n-\t\ttcp_send_active_reset(ssk, ssk-\u003esk_allocation,\n-\t\t\t\t      SK_RST_REASON_TCP_ABORT_ON_CLOSE);\n+\t\ttcp_send_active_reset(ssk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);\n unlock:\n \t\trelease_sock(ssk);\n \t}\ndiff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h\nindex 06a107d4e8392..87ccb84e9927c 100644\n--- a/net/mptcp/protocol.h\n+++ b/net/mptcp/protocol.h\n@@ -690,7 +690,7 @@ mptcp_send_active_reset_reason(struct sock *sk)\n \tenum sk_rst_reason reason;\n \n \treason = sk_rst_convert_mptcp_reason(subflow-\u003ereset_reason);\n-\ttcp_send_active_reset(sk, GFP_ATOMIC, reason);\n+\ttcp_send_active_reset(sk, reason);\n }\n \n /* Made the fwd mem carried by the given skb available to the msk,\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "INET",
    "MPTCP"
  ],
  "FocusSymbols": [
    "tcp_send_active_reset",
    "tcp_disconnect",
    "tcp_abort"
  ],
  "Reasoning": "The patch modifies the allocation flags for sending active TCP resets to always use GFP_ATOMIC, altering core TCP and MPTCP 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 ac2d12be99734465bcc567c8d446c6ed4909de79
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 03:33:34 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 670c20876f265..436495ff2271d 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -765,8 +765,7 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
 void tcp_send_probe0(struct sock *);
 int tcp_write_wakeup(struct sock *, int mib);
 void tcp_send_fin(struct sock *sk);
-void tcp_send_active_reset(struct sock *sk, gfp_t priority,
-			   enum sk_rst_reason reason);
+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason);
 int tcp_send_synack(struct sock *);
 void tcp_push_one(struct sock *, unsigned int mss_now);
 void __tcp_send_ack(struct sock *sk, u32 rcv_nxt, u16 flags);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b4237d0e994d6..93d723d8c1098 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3182,8 +3182,7 @@ void __tcp_close(struct sock *sk, long timeout)
 		/* Unread data was tossed, zap the connection. */
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
 		tcp_set_state(sk, TCP_CLOSE);
-		tcp_send_active_reset(sk, sk->sk_allocation,
-				      SK_RST_REASON_TCP_ABORT_ON_CLOSE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);
 	} else if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) {
 		/* Check zero linger _after_ checking for unread data. */
 		sk->sk_prot->disconnect(sk, 0);
@@ -3257,7 +3256,7 @@ void __tcp_close(struct sock *sk, long timeout)
 		struct tcp_sock *tp = tcp_sk(sk);
 		if (READ_ONCE(tp->linger2) < 0) {
 			tcp_set_state(sk, TCP_CLOSE);
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_LINGER);
 			__NET_INC_STATS(sock_net(sk),
 					LINUX_MIB_TCPABORTONLINGER);
@@ -3276,7 +3275,7 @@ void __tcp_close(struct sock *sk, long timeout)
 	if (sk->sk_state != TCP_CLOSE) {
 		if (tcp_check_oom(sk, 0)) {
 			tcp_set_state(sk, TCP_CLOSE);
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_MEMORY);
 			__NET_INC_STATS(sock_net(sk),
 					LINUX_MIB_TCPABORTONMEMORY);
@@ -3377,14 +3376,14 @@ int tcp_disconnect(struct sock *sk, int flags)
 	} else if (unlikely(tp->repair)) {
 		WRITE_ONCE(sk->sk_err, ECONNABORTED);
 	} else if (tcp_need_reset(old_state)) {
-		tcp_send_active_reset(sk, gfp_any(), SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 		WRITE_ONCE(sk->sk_err, ECONNRESET);
 	} else if (tp->snd_nxt != tp->write_seq &&
 		   (1 << old_state) & (TCPF_CLOSING | TCPF_LAST_ACK)) {
 		/* The last check adjusts for discrepancy of Linux wrt. RFC
 		 * states
 		 */
-		tcp_send_active_reset(sk, gfp_any(),
+		tcp_send_active_reset(sk,
 				      SK_RST_REASON_TCP_DISCONNECT_WITH_DATA);
 		WRITE_ONCE(sk->sk_err, ECONNRESET);
 	} else if (old_state == TCP_SYN_SENT)
@@ -5147,8 +5146,7 @@ int tcp_abort(struct sock *sk, int err)
 	bh_lock_sock(sk);
 
 	if (tcp_need_reset(sk->sk_state))
-		tcp_send_active_reset(sk, GFP_ATOMIC,
-				      SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 	tcp_done_with_error(sk, err);
 
 	bh_unlock_sock(sk);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index f2709d585edbd..19a799e5d5ce3 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3849,15 +3849,14 @@ void tcp_send_fin(struct sock *sk)
  * was unread data in the receive queue.  This behavior is recommended
  * by RFC 2525, section 2.17.  -DaveM
  */
-void tcp_send_active_reset(struct sock *sk, gfp_t priority,
-			   enum sk_rst_reason reason)
+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason)
 {
 	struct sk_buff *skb;
 
 	TCP_INC_STATS(sock_net(sk), TCP_MIB_OUTRSTS);
 
 	/* NOTE: No TCP options attached and we never retransmit this. */
-	skb = alloc_skb(MAX_TCP_HEADER, priority);
+	skb = alloc_skb(MAX_TCP_HEADER, GFP_ATOMIC);
 	if (!skb) {
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
 		return;
@@ -3869,7 +3868,7 @@ void tcp_send_active_reset(struct sock *sk, gfp_t priority,
 			     TCPHDR_ACK | TCPHDR_RST);
 	tcp_mstamp_refresh(tcp_sk(sk));
 	/* Send it off. */
-	if (tcp_transmit_skb(sk, skb, 0, priority))
+	if (tcp_transmit_skb(sk, skb, 0, GFP_ATOMIC))
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
 
 	/* skb of trace_tcp_send_reset() keeps the skb that caused RST,
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 1038e7ba9c2eb..e56eae4bc341e 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -126,7 +126,7 @@ static int tcp_out_of_resources(struct sock *sk, bool do_reset)
 		    (!tp->snd_wnd && !tp->packets_out))
 			do_reset = true;
 		if (do_reset)
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_MEMORY);
 		tcp_done(sk);
 		__NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONMEMORY);
@@ -809,7 +809,7 @@ static void tcp_keepalive_timer(struct timer_list *t)
 				goto out;
 			}
 		}
-		tcp_send_active_reset(sk, GFP_ATOMIC, SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 		goto death;
 	}
 
@@ -836,7 +836,7 @@ static void tcp_keepalive_timer(struct timer_list *t)
 		    icsk->icsk_probes_out > 0) ||
 		    (user_timeout == 0 &&
 		    icsk->icsk_probes_out >= keepalive_probes(tp))) {
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_KEEPALIVE_TIMEOUT);
 			tcp_write_err(sk);
 			goto out;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index b474d03620a75..e1f08f71cdb16 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3109,8 +3109,7 @@ static void mptcp_do_fastclose(struct sock *sk)
 		 */
 		inet_csk(ssk)->icsk_ack.rcv_mss = TCP_MIN_MSS;
 
-		tcp_send_active_reset(ssk, ssk->sk_allocation,
-				      SK_RST_REASON_TCP_ABORT_ON_CLOSE);
+		tcp_send_active_reset(ssk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);
 unlock:
 		release_sock(ssk);
 	}
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 06a107d4e8392..87ccb84e9927c 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -690,7 +690,7 @@ mptcp_send_active_reset_reason(struct sock *sk)
 	enum sk_rst_reason reason;
 
 	reason = sk_rst_convert_mptcp_reason(subflow->reset_reason);
-	tcp_send_active_reset(sk, GFP_ATOMIC, reason);
+	tcp_send_active_reset(sk, reason);
 }
 
 /* Made the fwd mem carried by the given skb available to the msk,

gemini-3.1-pro-preview

null

null

							input: 4637
							output: 22
							thoughts: 1017
						

**Analysis of a TCP/MPTCP Patch: Worth Fuzzing?**

Okay, so I'm looking at this patch that's modifying `tcp_send_active_reset` in `net/ipv4/tcp_output.c`. Essentially, it's removing the `priority` argument (which was a `gfp_t` value) and hardcoding `GFP_ATOMIC` inside the function.  It updates all the callers in `net/ipv4/tcp.c`, `net/ipv4/tcp_timer.c`, `net/mptcp/protocol.c`, and `net/mptcp/protocol.h`.

My initial thought is to figure out if this is a *functional* change. Previously, `tcp_send_active_reset` was called with a variety of `gfp_t` values, including `sk->sk_allocation` (which could be `GFP_KERNEL` or `GFP_USER`), and `GFP_ATOMIC` explicitly.  Now, it *always* uses `GFP_ATOMIC`. This *is* a functional change because it alters the allocation flags used by `alloc_skb` and `tcp_transmit_skb`.

The key concern is that by hardcoding `GFP_ATOMIC`, we're potentially introducing more allocation failures under memory pressure.  Or, perhaps, it's a valid simplification that just hardcodes a value already frequently used in these contexts.

The question then becomes: is this worth fuzzing?  It *does* modify core TCP logic, specifically how active resets are sent.  However, this doesn't introduce any new logic. It simply changes an allocation flag, a seemingly simple change.  But, wait, according to the rule, "Return WorthFuzzing=false if the patch only contains... Changes to numeric constants or macros that do not functionally alter execution flow". Changing `gfp_t` from `sk->sk_allocation` to `GFP_ATOMIC` might, in some very narrow edge cases, affect the execution flow if the allocation fails. Given the simplicity of the change but the core location, I need to look closer.

Okay, let me re-examine the patch.  It's just the removal of the `priority` parameter and the hardcoding. `tcp_send_active_reset` is definitely reachable and used in various parts.

Considering the potential for allocation failures, is it worth fuzzing?  Yes, this is a functional change within core TCP and MPTCP. Fuzzing might not *specifically* target the `GFP_ATOMIC` change, but it’s a change in reachable core kernel logic, and it’s better to be safe. I’m setting `WorthFuzzing=true`.

Therefore, I'll be focusing on the symbols `tcp_send_active_reset`, `tcp_disconnect`, and to a lesser degree `mptcp_do_fastclose`.  I need to check their visibility. `tcp_send_active_reset` is globally visible.  `mptcp_do_fastclose` is static, so I can ignore it for fuzzing purposes.  `tcp_disconnect` and `tcp_abort` are globally visible.

For configurations, I'll keep in mind that this involves both `MPTCP` and `INET`.

{
  "Expression": "void tcp_send_active_reset"
}

{
  "Output": "include/net/tcp.h=767=void tcp_send_fin(struct sock *sk);\ninclude/net/tcp.h:768:void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason);\ninclude/net/tcp.h-769-int tcp_send_synack(struct sock *);\n--\nnet/ipv4/tcp_output.c=3801=void tcp_send_fin(struct sock *sk)\n--\nnet/ipv4/tcp_output.c-3851- */\nnet/ipv4/tcp_output.c:3852:void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason)\nnet/ipv4/tcp_output.c-3853-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 6589
							output: 18
							thoughts: 15
						

Here's my attempt at summarizing that thought process, tailored for an expert audience:

**Analyzing Network Disconnection Visibility**

Okay, so I'm thinking about the visibility of a network disconnection. This situation is something I know is going to be globally visible. So, the question that comes to mind is how can I check it? Let me check the specifics by looking at `tcp_disconnect`. I can look there to find the information and know how to find it.

{
  "Expression": "int tcp_disconnect"
}

{
  "Output": "include/net/tcp.h=577=struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,\n--\ninclude/net/tcp.h-581-\t\t\t\tstruct sk_buff *syn_skb);\ninclude/net/tcp.h:582:int tcp_disconnect(struct sock *sk, int flags);\ninclude/net/tcp.h-583-\n--\nnet/ipv4/tcp.c=3345=void tcp_write_queue_purge(struct sock *sk)\n--\nnet/ipv4/tcp.c-3360-\nnet/ipv4/tcp.c:3361:int tcp_disconnect(struct sock *sk, int flags)\nnet/ipv4/tcp.c-3362-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 6926
							output: 18
							thoughts: 9
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Investigating `tcp_abort`**

Alright, time to get to it. Let's dig in and see what's happening with `tcp_abort`. It's a key function in handling connection termination, so I need to understand its role and behavior in the current context. A quick investigation of this specific function seems warranted. Time to get to it.

{
  "Expression": "int tcp_abort"
}

{
  "Output": "include/net/tcp.h=1704=void tcp_done(struct sock *sk);\ninclude/net/tcp.h:1705:int tcp_abort(struct sock *sk, int err);\ninclude/net/tcp.h-1706-\n--\nnet/ipv4/tcp.c=5079=void tcp_done(struct sock *sk)\n--\nnet/ipv4/tcp.c-5104-\nnet/ipv4/tcp.c:5105:int tcp_abort(struct sock *sk, int err)\nnet/ipv4/tcp.c-5106-{\n--\nnet/mptcp/subflow.c=2096=static void tcp_release_cb_override(struct sock *ssk)\n--\nnet/mptcp/subflow.c-2111-\nnet/mptcp/subflow.c:2112:static int tcp_abort_override(struct sock *ssk, int err)\nnet/mptcp/subflow.c-2113-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 7323
							output: 23
							thoughts: 14
						

Okay, here's my attempt at summarizing that thought process, keeping in mind I'm speaking to a fellow expert:

**Investigating `mptcp_do_fastclose`**

Alright, time to dig into this. "Let's check `mptcp_do_fastclose`." That's the starting point. I need to refresh my mental map of how MPTCP's fast close mechanism works. I'm probably looking for potential issues, bottlenecks, or areas that might be misbehaving based on some recent observations or bug reports. I’ll be thinking about how it interacts with the rest of the MPTCP stack, especially connection teardown and state transitions. I’ll need to remember the subtleties of the handshake and data transfer phases in relation to the fast close operation. Where’s that documentation? And I might be looking into some test scenarios to replicate issues and understand the implications of any code changes. This is going to be interesting. Time to dive in!

{
  "Expression": "void mptcp_do_fastclose"
}

{
  "Output": "net/mptcp/protocol.c=3065=static void mptcp_backlog_purge(struct sock *sk)\n--\nnet/mptcp/protocol.c-3082-\nnet/mptcp/protocol.c:3083:static void mptcp_do_fastclose(struct sock *sk)\nnet/mptcp/protocol.c-3084-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 7679
							output: 25
							thoughts: 22
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Analyzing a Potential Static Condition**

Okay, this feels static, doesn't it? Something's stuck. Let's dig in and figure out why. Since we're dealing with an MPTCP context, and the problem seems to be an unchanging state, the first thing that jumps to mind is the reset handling during the active path selection. Let's see if the reason for the lack of change, the blockage, can be found within the `mptcp_send_active_reset_reason` function, as that's where the path could stall. That seems the logical place to start digging.

{
  "Expression": "mptcp_send_active_reset_reason"
}

{
  "Output": "net/mptcp/protocol.c=2805=static void mptcp_check_fastclose(struct mptcp_sock *msk)\n--\nnet/mptcp/protocol.c-2820-\t\tif (tcp_sk-\u003esk_state != TCP_CLOSE) {\nnet/mptcp/protocol.c:2821:\t\t\tmptcp_send_active_reset_reason(tcp_sk);\nnet/mptcp/protocol.c-2822-\t\t\ttcp_set_state(tcp_sk, TCP_CLOSE);\n--\nnet/mptcp/protocol.h=686=static inline void\nnet/mptcp/protocol.h:687:mptcp_send_active_reset_reason(struct sock *sk)\nnet/mptcp/protocol.h-688-{\n--\nnet/mptcp/subflow.c=427=void mptcp_subflow_reset(struct sock *ssk)\n--\nnet/mptcp/subflow.c-440-\nnet/mptcp/subflow.c:441:\tmptcp_send_active_reset_reason(ssk);\nnet/mptcp/subflow.c-442-\ttcp_done(ssk);\n--\nnet/mptcp/subflow.c=1356=static bool subflow_check_data_avail(struct sock *ssk)\n--\nnet/mptcp/subflow.c-1437-\t\t\t\tsk_eat_skb(ssk, skb);\nnet/mptcp/subflow.c:1438:\t\t\tmptcp_send_active_reset_reason(ssk);\nnet/mptcp/subflow.c-1439-\t\t\tWRITE_ONCE(subflow-\u003edata_avail, false);\n"
}

gemini-3.1-pro-preview

null

null

							input: 8322
							output: 18
							thoughts: 69
						

**Analyzing Static Inline Functions and Configuration Dependencies**

Okay, so I'm looking at this code and it's using a `static inline` construct. That immediately flags certain function symbols as critical, particularly `tcp_send_active_reset`, `tcp_disconnect`, and `tcp_abort`. Those are the ones I need to focus on for this analysis, knowing they might be heavily optimized.

Now, considering the environment, I'm pretty sure `INET` is in play since we're dealing with TCP. But more importantly, the presence of these TCP-related functions likely indicates that `MPTCP` is also configured. I should double-check that `MPTCP` is indeed the right configuration name to confirm this intuition and ensure I'm targeting the correct configuration.

{
  "Expression": "config MPTCP"
}

{
  "Output": "net/mptcp/Kconfig-1-\nnet/mptcp/Kconfig:2:config MPTCP\nnet/mptcp/Kconfig-3-\tbool \"MPTCP: Multipath TCP\"\n--\nnet/mptcp/Kconfig=16=config INET_MPTCP_DIAG\n--\nnet/mptcp/Kconfig-19-\nnet/mptcp/Kconfig:20:config MPTCP_IPV6\nnet/mptcp/Kconfig-21-\tbool \"MPTCP: IPv6 support for Multipath TCP\"\n--\nnet/mptcp/Kconfig-24-\nnet/mptcp/Kconfig:25:config MPTCP_KUNIT_TEST\nnet/mptcp/Kconfig-26-\ttristate \"This builds the MPTCP KUnit tests\" if !KUNIT_ALL_TESTS\n"
}

gemini-3.1-pro-preview

null

null

							input: 8793
							output: 17
							thoughts: 35
						

**My Initial Assessment**

Okay, so I've confirmed that `MPTCP` is the correct protocol here. Good, good. Now, let's just make absolutely sure there aren't any other relevant configurations floating around. I need to be thorough; I have to account for any possibilities. Hmm, wait a minute, `TCP` itself isn't a *config*, it's the underlying transport protocol. It's more about `INET` layer. Got it. I'm on the right track here.

{
  "Expression": "config INET"
}

{
  "Output": "net/Kconfig=99=config NET_HANDSHAKE_KUNIT_TEST\n--\nnet/Kconfig-113-\nnet/Kconfig:114:config INET\nnet/Kconfig-115-\tbool \"TCP/IP networking\"\n--\nnet/ipv4/Kconfig=330=config NET_FOU_IP_TUNNELS\n--\nnet/ipv4/Kconfig-338-\nnet/ipv4/Kconfig:339:config INET_AH\nnet/ipv4/Kconfig-340-\ttristate \"IP: AH transformation\"\n--\nnet/ipv4/Kconfig-353-\nnet/ipv4/Kconfig:354:config INET_ESP\nnet/ipv4/Kconfig-355-\ttristate \"IP: ESP transformation\"\n--\nnet/ipv4/Kconfig-368-\nnet/ipv4/Kconfig:369:config INET_ESP_OFFLOAD\nnet/ipv4/Kconfig-370-\ttristate \"IP: ESP transformation offload\"\n--\nnet/ipv4/Kconfig-381-\nnet/ipv4/Kconfig:382:config INET_ESPINTCP\nnet/ipv4/Kconfig-383-\tbool \"IP: ESP in TCP encapsulation (RFC 8229)\"\n--\nnet/ipv4/Kconfig-393-\nnet/ipv4/Kconfig:394:config INET_IPCOMP\nnet/ipv4/Kconfig-395-\ttristate \"IP: IPComp transformation\"\n--\nnet/ipv4/Kconfig-403-\nnet/ipv4/Kconfig:404:config INET_TABLE_PERTURB_ORDER\nnet/ipv4/Kconfig-405-\tint \"INET: Source port perturbation table size (as power of 2)\" if EXPERT\n--\nnet/ipv4/Kconfig-413-\nnet/ipv4/Kconfig:414:config INET_XFRM_TUNNEL\nnet/ipv4/Kconfig-415-\ttristate\n--\nnet/ipv4/Kconfig-418-\nnet/ipv4/Kconfig:419:config INET_TUNNEL\nnet/ipv4/Kconfig-420-\ttristate\n--\nnet/ipv4/Kconfig-422-\nnet/ipv4/Kconfig:423:config INET_DIAG\nnet/ipv4/Kconfig-424-\ttristate \"INET: socket monitoring interface\"\n--\nnet/ipv4/Kconfig-434-\nnet/ipv4/Kconfig:435:config INET_TCP_DIAG\nnet/ipv4/Kconfig-436-\tdepends on INET_DIAG\n--\nnet/ipv4/Kconfig-438-\nnet/ipv4/Kconfig:439:config INET_UDP_DIAG\nnet/ipv4/Kconfig-440-\ttristate \"UDP: socket monitoring interface\"\n--\nnet/ipv4/Kconfig-446-\nnet/ipv4/Kconfig:447:config INET_RAW_DIAG\nnet/ipv4/Kconfig-448-\ttristate \"RAW: socket monitoring interface\"\n--\nnet/ipv4/Kconfig-454-\nnet/ipv4/Kconfig:455:config INET_DIAG_DESTROY\nnet/ipv4/Kconfig-456-\tbool \"INET: allow privileged process to administratively close sockets\"\n--\nnet/ipv6/Kconfig=39=config IPV6_OPTIMISTIC_DAD\n--\nnet/ipv6/Kconfig-46-\nnet/ipv6/Kconfig:47:config INET6_AH\nnet/ipv6/Kconfig-48-\ttristate \"IPv6: AH transformation\"\n--\nnet/ipv6/Kconfig-61-\nnet/ipv6/Kconfig:62:config INET6_ESP\nnet/ipv6/Kconfig-63-\ttristate \"IPv6: ESP transformation\"\n--\nnet/ipv6/Kconfig-76-\nnet/ipv6/Kconfig:77:config INET6_ESP_OFFLOAD\nnet/ipv6/Kconfig-78-\ttristate \"IPv6: ESP transformation offload\"\n--\nnet/ipv6/Kconfig-89-\nnet/ipv6/Kconfig:90:config INET6_ESPINTCP\nnet/ipv6/Kconfig-91-\tbool \"IPv6: ESP in TCP encapsulation (RFC 8229)\"\n--\nnet/ipv6/Kconfig-101-\nnet/ipv6/Kconfig:102:config INET6_IPCOMP\nnet/ipv6/Kconfig-103-\ttristate \"IPv6: IPComp transformation\"\n--\nnet/ipv6/Kconfig=120=config IPV6_ILA\n--\nnet/ipv6/Kconfig-140-\nnet/ipv6/Kconfig:141:config INET6_XFRM_TUNNEL\nnet/ipv6/Kconfig-142-\ttristate\n--\nnet/ipv6/Kconfig-145-\nnet/ipv6/Kconfig:146:config INET6_TUNNEL\nnet/ipv6/Kconfig-147-\ttristate\n--\nnet/mptcp/Kconfig=14=if MPTCP\nnet/mptcp/Kconfig-15-\nnet/mptcp/Kconfig:16:config INET_MPTCP_DIAG\nnet/mptcp/Kconfig-17-\tdepends on INET_DIAG\n--\nnet/psp/Kconfig-4-#\nnet/psp/Kconfig:5:config INET_PSP\nnet/psp/Kconfig-6-\tbool \"PSP Security Protocol support\"\n--\nnet/sctp/Kconfig=68=endchoice\nnet/sctp/Kconfig-69-\nnet/sctp/Kconfig:70:config INET_SCTP_DIAG\nnet/sctp/Kconfig-71-\tdepends on INET_DIAG\n"
}

gemini-3.1-pro-preview

null

null

							input: 10468
							output: 88
							thoughts: 84
						

**My Analysis of this TCP Patch**

Okay, so this patch is all about TCP configuration, specifically the `INET` module. Let's break down the key takeaways. This change is deemed `WorthFuzzing`, which means it's a potential area for security vulnerabilities, so it warrants a closer look. The core issue revolves around how active TCP resets are handled, specifically, how allocation flags are used when they're sent. The patch modifies the core TCP and MPTCP logic to *always* use `GFP_ATOMIC` for these allocations.

My reasoning suggests that this change in allocation flags has the potential to introduce subtle issues, especially in high-load or resource-constrained environments. We really need to understand the implications of switching to `GFP_ATOMIC` for these critical network operations.

The functions to focus my attention on are `tcp_send_active_reset`, `tcp_disconnect`, and `tcp_abort`. I'll want to trace the execution path of those functions and see how this new `GFP_ATOMIC` usage impacts them.

The necessary configurations to reproduce the target are `INET` and `MPTCP`.

{
  "EnableConfigs": [
    "INET",
    "MPTCP"
  ],
  "FocusSymbols": [
    "tcp_send_active_reset",
    "tcp_disconnect",
    "tcp_abort"
  ],
  "Reasoning": "The patch modifies the allocation flags for sending active TCP resets to always use GFP_ATOMIC, altering core TCP and MPTCP logic.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "INET",
    "MPTCP"
  ],
  "FocusSymbols": [
    "tcp_send_active_reset",
    "tcp_disconnect",
    "tcp_abort"
  ],
  "Reasoning": "The patch modifies the allocation flags for sending active TCP resets to always use GFP_ATOMIC, altering core TCP and MPTCP logic.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch removes the `gfp_t priority` argument from `tcp_send_active_reset()` and hardcodes `GFP_ATOMIC` for the SKB allocation and transmission. This is a simple refactoring of memory allocation flags and does not introduce any new data structures, modify buffer lengths, or alter initialization logic. There is no risk of exposing uninitialized memory to user space or using it in control flow. Standard KASAN and other bug detectors are perfectly adequate to catch any potential issues related to this change.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
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 ac2d12be99734465bcc567c8d446c6ed4909de79
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 25 03:33:34 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 670c20876f265..436495ff2271d 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -765,8 +765,7 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
 void tcp_send_probe0(struct sock *);
 int tcp_write_wakeup(struct sock *, int mib);
 void tcp_send_fin(struct sock *sk);
-void tcp_send_active_reset(struct sock *sk, gfp_t priority,
-			   enum sk_rst_reason reason);
+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason);
 int tcp_send_synack(struct sock *);
 void tcp_push_one(struct sock *, unsigned int mss_now);
 void __tcp_send_ack(struct sock *sk, u32 rcv_nxt, u16 flags);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index b4237d0e994d6..93d723d8c1098 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3182,8 +3182,7 @@ void __tcp_close(struct sock *sk, long timeout)
 		/* Unread data was tossed, zap the connection. */
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONCLOSE);
 		tcp_set_state(sk, TCP_CLOSE);
-		tcp_send_active_reset(sk, sk->sk_allocation,
-				      SK_RST_REASON_TCP_ABORT_ON_CLOSE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);
 	} else if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) {
 		/* Check zero linger _after_ checking for unread data. */
 		sk->sk_prot->disconnect(sk, 0);
@@ -3257,7 +3256,7 @@ void __tcp_close(struct sock *sk, long timeout)
 		struct tcp_sock *tp = tcp_sk(sk);
 		if (READ_ONCE(tp->linger2) < 0) {
 			tcp_set_state(sk, TCP_CLOSE);
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_LINGER);
 			__NET_INC_STATS(sock_net(sk),
 					LINUX_MIB_TCPABORTONLINGER);
@@ -3276,7 +3275,7 @@ void __tcp_close(struct sock *sk, long timeout)
 	if (sk->sk_state != TCP_CLOSE) {
 		if (tcp_check_oom(sk, 0)) {
 			tcp_set_state(sk, TCP_CLOSE);
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_MEMORY);
 			__NET_INC_STATS(sock_net(sk),
 					LINUX_MIB_TCPABORTONMEMORY);
@@ -3377,14 +3376,14 @@ int tcp_disconnect(struct sock *sk, int flags)
 	} else if (unlikely(tp->repair)) {
 		WRITE_ONCE(sk->sk_err, ECONNABORTED);
 	} else if (tcp_need_reset(old_state)) {
-		tcp_send_active_reset(sk, gfp_any(), SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 		WRITE_ONCE(sk->sk_err, ECONNRESET);
 	} else if (tp->snd_nxt != tp->write_seq &&
 		   (1 << old_state) & (TCPF_CLOSING | TCPF_LAST_ACK)) {
 		/* The last check adjusts for discrepancy of Linux wrt. RFC
 		 * states
 		 */
-		tcp_send_active_reset(sk, gfp_any(),
+		tcp_send_active_reset(sk,
 				      SK_RST_REASON_TCP_DISCONNECT_WITH_DATA);
 		WRITE_ONCE(sk->sk_err, ECONNRESET);
 	} else if (old_state == TCP_SYN_SENT)
@@ -5147,8 +5146,7 @@ int tcp_abort(struct sock *sk, int err)
 	bh_lock_sock(sk);
 
 	if (tcp_need_reset(sk->sk_state))
-		tcp_send_active_reset(sk, GFP_ATOMIC,
-				      SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 	tcp_done_with_error(sk, err);
 
 	bh_unlock_sock(sk);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index f2709d585edbd..19a799e5d5ce3 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3849,15 +3849,14 @@ void tcp_send_fin(struct sock *sk)
  * was unread data in the receive queue.  This behavior is recommended
  * by RFC 2525, section 2.17.  -DaveM
  */
-void tcp_send_active_reset(struct sock *sk, gfp_t priority,
-			   enum sk_rst_reason reason)
+void tcp_send_active_reset(struct sock *sk, enum sk_rst_reason reason)
 {
 	struct sk_buff *skb;
 
 	TCP_INC_STATS(sock_net(sk), TCP_MIB_OUTRSTS);
 
 	/* NOTE: No TCP options attached and we never retransmit this. */
-	skb = alloc_skb(MAX_TCP_HEADER, priority);
+	skb = alloc_skb(MAX_TCP_HEADER, GFP_ATOMIC);
 	if (!skb) {
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
 		return;
@@ -3869,7 +3868,7 @@ void tcp_send_active_reset(struct sock *sk, gfp_t priority,
 			     TCPHDR_ACK | TCPHDR_RST);
 	tcp_mstamp_refresh(tcp_sk(sk));
 	/* Send it off. */
-	if (tcp_transmit_skb(sk, skb, 0, priority))
+	if (tcp_transmit_skb(sk, skb, 0, GFP_ATOMIC))
 		NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTFAILED);
 
 	/* skb of trace_tcp_send_reset() keeps the skb that caused RST,
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 1038e7ba9c2eb..e56eae4bc341e 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -126,7 +126,7 @@ static int tcp_out_of_resources(struct sock *sk, bool do_reset)
 		    (!tp->snd_wnd && !tp->packets_out))
 			do_reset = true;
 		if (do_reset)
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_ABORT_ON_MEMORY);
 		tcp_done(sk);
 		__NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONMEMORY);
@@ -809,7 +809,7 @@ static void tcp_keepalive_timer(struct timer_list *t)
 				goto out;
 			}
 		}
-		tcp_send_active_reset(sk, GFP_ATOMIC, SK_RST_REASON_TCP_STATE);
+		tcp_send_active_reset(sk, SK_RST_REASON_TCP_STATE);
 		goto death;
 	}
 
@@ -836,7 +836,7 @@ static void tcp_keepalive_timer(struct timer_list *t)
 		    icsk->icsk_probes_out > 0) ||
 		    (user_timeout == 0 &&
 		    icsk->icsk_probes_out >= keepalive_probes(tp))) {
-			tcp_send_active_reset(sk, GFP_ATOMIC,
+			tcp_send_active_reset(sk,
 					      SK_RST_REASON_TCP_KEEPALIVE_TIMEOUT);
 			tcp_write_err(sk);
 			goto out;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index b474d03620a75..e1f08f71cdb16 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3109,8 +3109,7 @@ static void mptcp_do_fastclose(struct sock *sk)
 		 */
 		inet_csk(ssk)->icsk_ack.rcv_mss = TCP_MIN_MSS;
 
-		tcp_send_active_reset(ssk, ssk->sk_allocation,
-				      SK_RST_REASON_TCP_ABORT_ON_CLOSE);
+		tcp_send_active_reset(ssk, SK_RST_REASON_TCP_ABORT_ON_CLOSE);
 unlock:
 		release_sock(ssk);
 	}
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 06a107d4e8392..87ccb84e9927c 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -690,7 +690,7 @@ mptcp_send_active_reset_reason(struct sock *sk)
 	enum sk_rst_reason reason;
 
 	reason = sk_rst_convert_mptcp_reason(subflow->reset_reason);
-	tcp_send_active_reset(sk, GFP_ATOMIC, reason);
+	tcp_send_active_reset(sk, reason);
 }
 
 /* Made the fwd mem carried by the given skb available to the msk,

gemini-3.1-pro-preview

null

null

							input: 4634
							output: 133
							thoughts: 525
						

**Analysis of the TCP Reset Patch**

Okay, so this patch is straightforward. Essentially, I'm seeing that the `tcp_send_active_reset` function's signature is being streamlined. The `gfp_t priority` parameter is being dropped. Instead of dynamically passing the memory allocation priority flag to `alloc_skb` and `tcp_transmit_skb`, the patch hardcodes `GFP_ATOMIC`.

Specifically, the diffs show: the function signature itself is changing, and inside `tcp_send_active_reset`, the `alloc_skb` call and the `tcp_transmit_skb` call now use the hardcoded `GFP_ATOMIC`. Naturally, all the calling sites for this function have also been updated to reflect the signature change, removing the now-unnecessary `priority` argument.

The key question is, does this introduce any uninitialized memory vulnerabilities? After looking it over carefully, the answer is no. This patch *only* changes the memory allocation flags used by the SKB. It’s a pure refactoring and simplification, replacing a variable with a constant. It's not introducing any new fields, modifying data structures or sizes, or changing how data is initialized. I'm satisfied that the existing SKB allocation/initialization logic in the networking stack, which handles header creation and data setup, isn't being altered, just the allocation context. `alloc_skb` itself doesn't zero the data, but the subsequent calls within the network stack guarantee that everything is properly initialized before transmission.

Therefore, given the nature of the change, a dedicated KMSAN fuzzing session isn't warranted. Standard KASAN and other bug detectors are perfectly adequate to catch any potential memory issues this refactoring *could* introduce - though I don't see any real risk. The patch primarily alters memory allocation flags within a well-established and tested code path.

{
  "KMSANReasoning": "The patch removes the `gfp_t priority` argument from `tcp_send_active_reset()` and hardcodes `GFP_ATOMIC` for the SKB allocation and transmission. This is a simple refactoring of memory allocation flags and does not introduce any new data structures, modify buffer lengths, or alter initialization logic. There is no risk of exposing uninitialized memory to user space or using it in control flow. Standard KASAN and other bug detectors are perfectly adequate to catch any potential issues related to this change.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch removes the `gfp_t priority` argument from `tcp_send_active_reset()` and hardcodes `GFP_ATOMIC` for the SKB allocation and transmission. This is a simple refactoring of memory allocation flags and does not introduce any new data structures, modify buffer lengths, or alter initialization logic. There is no risk of exposing uninitialized memory to user space or using it in control flow. Standard KASAN and other bug detectors are perfectly adequate to catch any potential issues related to this change.",
  "NeedsKMSAN": false
}