AI Trajectory

null

{
  "EnableConfigs": [
    "MPTCP"
  ],
  "FocusSymbols": [
    "mptcp_fastopen_subflow_synack_set_params",
    "mptcp_subflow_init_cookie_req",
    "mptcp_pm_announced_alloc",
    "mptcp_pm_destroy",
    "mptcp_userspace_pm_get_local_id",
    "mptcp_pm_nl_announce_doit",
    "mptcp_pm_nl_subflow_create_doit"
  ],
  "Reasoning": "The patch series makes functional changes to the MPTCP protocol implementation, including option validation, memory reclamation, and PM destruction handling. These are core networking features that should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit a17994fc0ab3fb8067d5304d56a16498cedf5be3\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Aug 3 19:45:12 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c\nindex 082c46c0f50ee..f717750906ffa 100644\n--- a/net/mptcp/fastopen.c\n+++ b/net/mptcp/fastopen.c\n@@ -24,12 +24,13 @@ void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subf\n \tsk = subflow-\u003econn;\n \ttp = tcp_sk(ssk);\n \n-\tsubflow-\u003eis_mptfo = 1;\n-\n+\t/* A valid TFO cookie does not guarantee SYN data. */\n \tskb = skb_peek(\u0026ssk-\u003esk_receive_queue);\n-\tif (WARN_ON_ONCE(!skb))\n+\tif (!skb)\n \t\treturn;\n \n+\tsubflow-\u003eis_mptfo = 1;\n+\n \t/* dequeue the skb from sk receive queue */\n \t__skb_unlink(skb, \u0026ssk-\u003esk_receive_queue);\n \tskb_ext_reset(skb);\ndiff --git a/net/mptcp/options.c b/net/mptcp/options.c\nindex c664023d37ba8..1057d500577b0 100644\n--- a/net/mptcp/options.c\n+++ b/net/mptcp/options.c\n@@ -50,6 +50,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\t\t}\n \t\t}\n \n+\t\t/* Only the MPC + ACK can be used with a RM_ADDR */\n+\t\tif (subopt == OPTION_MPTCP_MPC_ACK) {\n+\t\t\tif ((mp_opt-\u003esuboptions \u0026 ~OPTION_MPTCP_RM_ADDR) != 0)\n+\t\t\t\tbreak;\n+\t\t} else if (mp_opt-\u003esuboptions != 0) {\n+\t\t\tbreak;\n+\t\t}\n+\n \t\t/* Cfr RFC 8684 Section 3.3.0:\n \t\t * If a checksum is present but its use had\n \t\t * not been negotiated in the MP_CAPABLE handshake, the receiver MUST\n@@ -122,6 +130,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_MP_JOIN:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTION_MPTCP_RM_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_PRIO)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize == TCPOLEN_MPTCP_MPJ_SYN) {\n \t\t\tmp_opt-\u003esuboptions |= OPTION_MPTCP_MPJ_SYN;\n \t\t\tmp_opt-\u003ebackup = *ptr++ \u0026 MPTCPOPT_BACKUP;\n@@ -153,6 +166,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_DSS:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTION_MPTCP_ADD_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_RM_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_PRIO |\n+\t\t\t\t\t    OPTION_MPTCP_FASTCLOSE |\n+\t\t\t\t\t    OPTION_MPTCP_FAIL)) != 0)\n+\t\t\tbreak;\n+\n \t\tpr_debug(\"DSS\\n\");\n \t\tptr++;\n \n@@ -188,8 +209,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\t * RFC 8684 Section 3.3.0 checks later in subflow_data_ready\n \t\t */\n \t\tif (opsize != expected_opsize \u0026\u0026\n-\t\t    opsize != expected_opsize + TCPOLEN_MPTCP_DSS_CHECKSUM)\n+\t\t    opsize != expected_opsize + TCPOLEN_MPTCP_DSS_CHECKSUM) {\n+\t\t\tmp_opt-\u003edsn64 = 0;\n+\t\t\tmp_opt-\u003euse_map = 0;\n+\t\t\tmp_opt-\u003eack64 = 0;\n+\t\t\tmp_opt-\u003euse_ack = 0;\n+\t\t\tmp_opt-\u003edata_fin = 0;\n \t\t\tbreak;\n+\t\t}\n \n \t\tmp_opt-\u003esuboptions |= OPTION_MPTCP_DSS;\n \t\tif (mp_opt-\u003euse_ack) {\n@@ -234,6 +261,12 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_ADD_ADDR:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTIONS_MPTCP_DSS |\n+\t\t\t\t\t    OPTION_MPTCP_RM_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_PRIO)) != 0)\n+\t\t\tbreak;\n+\n \t\tmp_opt-\u003eecho = (*ptr++) \u0026 MPTCP_ADDR_ECHO;\n \t\tif (!mp_opt-\u003eecho) {\n \t\t\tif (opsize == TCPOLEN_MPTCP_ADD_ADDR ||\n@@ -293,6 +326,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_RM_ADDR:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTION_MPTCP_MPC_ACK |\n+\t\t\t\t\t    OPTIONS_MPTCP_MPJ |\n+\t\t\t\t\t    OPTIONS_MPTCP_DSS |\n+\t\t\t\t\t    OPTION_MPTCP_ADD_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_PRIO)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize \u003c TCPOLEN_MPTCP_RM_ADDR_BASE + 1 ||\n \t\t    opsize \u003e TCPOLEN_MPTCP_RM_ADDR_BASE + MPTCP_RM_IDS_MAX)\n \t\t\tbreak;\n@@ -307,6 +348,13 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_MP_PRIO:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTIONS_MPTCP_MPJ |\n+\t\t\t\t\t    OPTIONS_MPTCP_DSS |\n+\t\t\t\t\t    OPTION_MPTCP_ADD_ADDR |\n+\t\t\t\t\t    OPTION_MPTCP_RM_ADDR)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize != TCPOLEN_MPTCP_PRIO)\n \t\t\tbreak;\n \n@@ -316,6 +364,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_MP_FASTCLOSE:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTIONS_MPTCP_DSS |\n+\t\t\t\t\t    OPTION_MPTCP_RST)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize != TCPOLEN_MPTCP_FASTCLOSE)\n \t\t\tbreak;\n \n@@ -327,6 +380,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_RST:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTION_MPTCP_FAIL |\n+\t\t\t\t\t    OPTION_MPTCP_FASTCLOSE)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize != TCPOLEN_MPTCP_RST)\n \t\t\tbreak;\n \n@@ -342,6 +400,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,\n \t\tbreak;\n \n \tcase MPTCPOPT_MP_FAIL:\n+\t\t/* Can be used with a restricted number of other options */\n+\t\tif ((mp_opt-\u003esuboptions \u0026 ~(OPTIONS_MPTCP_DSS |\n+\t\t\t\t\t    OPTION_MPTCP_RST)) != 0)\n+\t\t\tbreak;\n+\n \t\tif (opsize != TCPOLEN_MPTCP_FAIL)\n \t\t\tbreak;\n \n@@ -1400,7 +1463,7 @@ void mptcp_write_options(struct tcphdr *th, __be32 *ptr, struct tcp_sock *tp,\n \t *  RM   |  C   |  C   |  C   |  P   |------|------|------|------|\n \t *  PRIO |  X   |  C   |  C   |  C   |  C   |------|------|------|\n \t *  FAIL |  X   |  X   |  C   |  X   |  X   |  X   |------|------|\n-\t *  FC   |  X   |  X   |  X   |  X   |  X   |  X   |  X   |------|\n+\t *  FC   |  X   |  X   |  P   |  X   |  X   |  X   |  X   |------|\n \t *  RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |\n \t * ------|------|------|------|------|------|------|------|------|\n \t *\ndiff --git a/net/mptcp/pm.c b/net/mptcp/pm.c\nindex 6afd39aea110a..64a1236aabee9 100644\n--- a/net/mptcp/pm.c\n+++ b/net/mptcp/pm.c\n@@ -380,6 +380,7 @@ static void mptcp_pm_add_addr_timer(struct timer_list *timer)\n \tstruct mptcp_sock *msk = entry-\u003esock;\n \tstruct sock *sk = (struct sock *)msk;\n \tunsigned int timeout = 0;\n+\tbool retransmit;\n \n \tpr_debug(\"msk=%p\\n\", msk);\n \n@@ -412,14 +413,15 @@ static void mptcp_pm_add_addr_timer(struct timer_list *timer)\n \t\tentry-\u003eretrans_times++;\n \t}\n \n-\tif (entry-\u003eretrans_times \u003c ADD_ADDR_RETRANS_MAX)\n+\tretransmit = entry-\u003eretrans_times \u003c ADD_ADDR_RETRANS_MAX;\n+\tif (retransmit)\n \t\ttimeout \u003c\u003c= entry-\u003eretrans_times;\n \telse\n \t\ttimeout = 0;\n \n \tspin_unlock_bh(\u0026msk-\u003epm.lock);\n \n-\tif (entry-\u003eretrans_times == ADD_ADDR_RETRANS_MAX)\n+\tif (!retransmit)\n \t\tmptcp_pm_subflow_established(msk);\n \n out:\n@@ -441,6 +443,9 @@ bool mptcp_pm_announced_alloc(struct mptcp_sock *msk,\n \n \tlockdep_assert_held(\u0026msk-\u003epm.lock);\n \n+\tif (msk-\u003epm.status \u0026 BIT(MPTCP_PM_DESTROYING))\n+\t\treturn false;\n+\n \tadd_entry = mptcp_pm_announced_lookup(msk, addr);\n \tif (add_entry) {\n \t\tif (WARN_ON_ONCE(mptcp_pm_is_kernel(msk)))\n@@ -1143,10 +1148,16 @@ void mptcp_pm_worker(struct mptcp_sock *msk)\n \n void mptcp_pm_destroy(struct mptcp_sock *msk)\n {\n+\tspin_lock_bh(\u0026msk-\u003epm.lock);\n+\tmsk-\u003epm.status |= BIT(MPTCP_PM_DESTROYING);\n+\tspin_unlock_bh(\u0026msk-\u003epm.lock);\n+\n \tmptcp_pm_free_announced_list(msk);\n \n-\tif (mptcp_pm_is_userspace(msk))\n-\t\tmptcp_userspace_pm_free_local_addr_list(msk);\n+\t/* Free the userspace local address list unconditionally: the socket\n+\t * can be reused (mptcp_disconnect()) and re-selected to a different PM\n+\t */\n+\tmptcp_userspace_pm_free_local_addr_list(msk);\n }\n \n void mptcp_pm_data_reset(struct mptcp_sock *msk)\ndiff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c\nindex 945aa5afc2ddf..2203cc2d27485 100644\n--- a/net/mptcp/pm_userspace.c\n+++ b/net/mptcp/pm_userspace.c\n@@ -54,6 +54,10 @@ static int mptcp_userspace_pm_append_new_local_addr(struct mptcp_sock *msk,\n \tbitmap_zero(id_bitmap, MPTCP_PM_MAX_ADDR_ID + 1);\n \n \tspin_lock_bh(\u0026msk-\u003epm.lock);\n+\tif (msk-\u003epm.status \u0026 BIT(MPTCP_PM_DESTROYING)) {\n+\t\tret = -EINVAL;\n+\t\tgoto append_err;\n+\t}\n \tmptcp_for_each_userspace_pm_addr(msk, e) {\n \t\taddr_match = mptcp_addresses_equal(\u0026e-\u003eaddr, \u0026entry-\u003eaddr, true);\n \t\tif (addr_match \u0026\u0026 entry-\u003eaddr.id == 0 \u0026\u0026 needs_id)\ndiff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c\nindex ca644ec53eedb..7c8180d8d5eff 100644\n--- a/net/mptcp/protocol.c\n+++ b/net/mptcp/protocol.c\n@@ -149,6 +149,12 @@ struct sock *__mptcp_nmpc_sk(struct mptcp_sock *msk)\n \n static void mptcp_drop(struct sock *sk, struct sk_buff *skb)\n {\n+\t/* The skb forward memory was already transferred to sk by\n+\t * mptcp_borrow_fwdmem(), even before setting the destructor.\n+\t */\n+\tif (!skb-\u003edestructor)\n+\t\tsk_mem_reclaim(sk);\n+\n \tsk_drops_skbadd(sk, skb);\n \t__kfree_skb(skb);\n }\ndiff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h\nindex 4a2d40cd7b132..1b80f2d6ec5a2 100644\n--- a/net/mptcp/protocol.h\n+++ b/net/mptcp/protocol.h\n@@ -37,6 +37,7 @@\n \t\t\t\t OPTION_MPTCP_MPC_ACK)\n #define OPTIONS_MPTCP_MPJ\t(OPTION_MPTCP_MPJ_SYN | OPTION_MPTCP_MPJ_SYNACK | \\\n \t\t\t\t OPTION_MPTCP_MPJ_ACK)\n+#define OPTIONS_MPTCP_DSS\t(OPTION_MPTCP_DSS | OPTION_MPTCP_CSUMREQD)\n \n /* MPTCP option subtypes */\n #define MPTCPOPT_MP_CAPABLE\t0\n@@ -189,9 +190,10 @@ enum mptcp_pm_status {\n \tMPTCP_PM_ESTABLISHED,\n \tMPTCP_PM_SUBFLOW_ESTABLISHED,\n \tMPTCP_PM_ALREADY_ESTABLISHED,\t/* persistent status, set after ESTABLISHED event */\n-\tMPTCP_PM_MPC_ENDPOINT_ACCOUNTED /* persistent status, set after MPC local address is\n-\t\t\t\t\t * accounted int id_avail_bitmap\n-\t\t\t\t\t */\n+\tMPTCP_PM_MPC_ENDPOINT_ACCOUNTED, /* persistent status, set after MPC local address is\n+\t\t\t\t\t  * accounted int id_avail_bitmap\n+\t\t\t\t\t  */\n+\tMPTCP_PM_DESTROYING,\t\t/* To fence out PM list allocs */\n };\n \n enum mptcp_pm_type {\ndiff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c\nindex 8e386899ceb98..e1f20ff8fdb42 100644\n--- a/net/mptcp/subflow.c\n+++ b/net/mptcp/subflow.c\n@@ -174,8 +174,6 @@ static int subflow_check_req(struct request_sock *req,\n \n \t\tif (unlikely(listener-\u003epm_listener))\n \t\t\treturn subflow_reset_req_endp(req, skb);\n-\t\tif (opt_mp_join)\n-\t\t\treturn 0;\n \t} else if (opt_mp_join) {\n \t\tSUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINSYNRX);\n \n@@ -277,9 +275,6 @@ int mptcp_subflow_init_cookie_req(struct request_sock *req,\n \n \topt_mp_capable = !!(mp_opt.suboptions \u0026 OPTION_MPTCP_MPC_ACK);\n \topt_mp_join = !!(mp_opt.suboptions \u0026 OPTION_MPTCP_MPJ_ACK);\n-\tif (opt_mp_capable \u0026\u0026 opt_mp_join)\n-\t\treturn -EINVAL;\n-\n \tif (opt_mp_capable \u0026\u0026 listener-\u003erequest_mptcp) {\n \t\tif (mp_opt.sndr_key == 0)\n \t\t\treturn -EINVAL;\ndiff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh\nindex c0aeffd5cb714..7dc91fac4917e 100755\n--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh\n+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh\n@@ -584,7 +584,7 @@ check_transfer()\n \t\tmv \"$tmpfile\" \"$out\"\n \t\ttmpfile=\"\"\n \tfi\n-\tcmp -l \"$in\" \"$out\" | while read -r i a b; do\n+\twhile read -r i a b; do\n \t\tlocal sum=$((0${a} + 0${b}))\n \t\tif [ $check_invert -eq 0 ] || [ $sum -ne $((0xff)) ]; then\n \t\t\tfail_test \"$what does not match (in, out):\"\n@@ -595,7 +595,7 @@ check_transfer()\n \t\telse\n \t\t\tprint_info \"$what has inverted byte at ${i}\"\n \t\tfi\n-\tdone\n+\tdone \u003c \u003c(cmp -l \"$in\" \"$out\")\n \n \treturn 0\n }\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "MPTCP"
  ],
  "FocusSymbols": [
    "mptcp_fastopen_subflow_synack_set_params",
    "mptcp_subflow_init_cookie_req",
    "mptcp_pm_announced_alloc",
    "mptcp_pm_destroy",
    "mptcp_userspace_pm_get_local_id",
    "mptcp_pm_nl_announce_doit",
    "mptcp_pm_nl_subflow_create_doit"
  ],
  "Reasoning": "The patch series makes functional changes to the MPTCP protocol implementation, including option validation, memory reclamation, and PM destruction handling. These are core networking features that should be fuzzed.",
  "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 a17994fc0ab3fb8067d5304d56a16498cedf5be3
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Aug 3 19:45:12 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/mptcp/fastopen.c b/net/mptcp/fastopen.c
index 082c46c0f50ee..f717750906ffa 100644
--- a/net/mptcp/fastopen.c
+++ b/net/mptcp/fastopen.c
@@ -24,12 +24,13 @@ void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subf
 	sk = subflow->conn;
 	tp = tcp_sk(ssk);
 
-	subflow->is_mptfo = 1;
-
+	/* A valid TFO cookie does not guarantee SYN data. */
 	skb = skb_peek(&ssk->sk_receive_queue);
-	if (WARN_ON_ONCE(!skb))
+	if (!skb)
 		return;
 
+	subflow->is_mptfo = 1;
+
 	/* dequeue the skb from sk receive queue */
 	__skb_unlink(skb, &ssk->sk_receive_queue);
 	skb_ext_reset(skb);
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index c664023d37ba8..1057d500577b0 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -50,6 +50,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 			}
 		}
 
+		/* Only the MPC + ACK can be used with a RM_ADDR */
+		if (subopt == OPTION_MPTCP_MPC_ACK) {
+			if ((mp_opt->suboptions & ~OPTION_MPTCP_RM_ADDR) != 0)
+				break;
+		} else if (mp_opt->suboptions != 0) {
+			break;
+		}
+
 		/* Cfr RFC 8684 Section 3.3.0:
 		 * If a checksum is present but its use had
 		 * not been negotiated in the MP_CAPABLE handshake, the receiver MUST
@@ -122,6 +130,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_MP_JOIN:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTION_MPTCP_RM_ADDR |
+					    OPTION_MPTCP_PRIO)) != 0)
+			break;
+
 		if (opsize == TCPOLEN_MPTCP_MPJ_SYN) {
 			mp_opt->suboptions |= OPTION_MPTCP_MPJ_SYN;
 			mp_opt->backup = *ptr++ & MPTCPOPT_BACKUP;
@@ -153,6 +166,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_DSS:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTION_MPTCP_ADD_ADDR |
+					    OPTION_MPTCP_RM_ADDR |
+					    OPTION_MPTCP_PRIO |
+					    OPTION_MPTCP_FASTCLOSE |
+					    OPTION_MPTCP_FAIL)) != 0)
+			break;
+
 		pr_debug("DSS\n");
 		ptr++;
 
@@ -188,8 +209,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		 * RFC 8684 Section 3.3.0 checks later in subflow_data_ready
 		 */
 		if (opsize != expected_opsize &&
-		    opsize != expected_opsize + TCPOLEN_MPTCP_DSS_CHECKSUM)
+		    opsize != expected_opsize + TCPOLEN_MPTCP_DSS_CHECKSUM) {
+			mp_opt->dsn64 = 0;
+			mp_opt->use_map = 0;
+			mp_opt->ack64 = 0;
+			mp_opt->use_ack = 0;
+			mp_opt->data_fin = 0;
 			break;
+		}
 
 		mp_opt->suboptions |= OPTION_MPTCP_DSS;
 		if (mp_opt->use_ack) {
@@ -234,6 +261,12 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_ADD_ADDR:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_DSS |
+					    OPTION_MPTCP_RM_ADDR |
+					    OPTION_MPTCP_PRIO)) != 0)
+			break;
+
 		mp_opt->echo = (*ptr++) & MPTCP_ADDR_ECHO;
 		if (!mp_opt->echo) {
 			if (opsize == TCPOLEN_MPTCP_ADD_ADDR ||
@@ -293,6 +326,14 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_RM_ADDR:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTION_MPTCP_MPC_ACK |
+					    OPTIONS_MPTCP_MPJ |
+					    OPTIONS_MPTCP_DSS |
+					    OPTION_MPTCP_ADD_ADDR |
+					    OPTION_MPTCP_PRIO)) != 0)
+			break;
+
 		if (opsize < TCPOLEN_MPTCP_RM_ADDR_BASE + 1 ||
 		    opsize > TCPOLEN_MPTCP_RM_ADDR_BASE + MPTCP_RM_IDS_MAX)
 			break;
@@ -307,6 +348,13 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_MP_PRIO:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_MPJ |
+					    OPTIONS_MPTCP_DSS |
+					    OPTION_MPTCP_ADD_ADDR |
+					    OPTION_MPTCP_RM_ADDR)) != 0)
+			break;
+
 		if (opsize != TCPOLEN_MPTCP_PRIO)
 			break;
 
@@ -316,6 +364,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_MP_FASTCLOSE:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_DSS |
+					    OPTION_MPTCP_RST)) != 0)
+			break;
+
 		if (opsize != TCPOLEN_MPTCP_FASTCLOSE)
 			break;
 
@@ -327,6 +380,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_RST:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTION_MPTCP_FAIL |
+					    OPTION_MPTCP_FASTCLOSE)) != 0)
+			break;
+
 		if (opsize != TCPOLEN_MPTCP_RST)
 			break;
 
@@ -342,6 +400,11 @@ static void mptcp_parse_option(const struct sk_buff *skb,
 		break;
 
 	case MPTCPOPT_MP_FAIL:
+		/* Can be used with a restricted number of other options */
+		if ((mp_opt->suboptions & ~(OPTIONS_MPTCP_DSS |
+					    OPTION_MPTCP_RST)) != 0)
+			break;
+
 		if (opsize != TCPOLEN_MPTCP_FAIL)
 			break;
 
@@ -1400,7 +1463,7 @@ void mptcp_write_options(struct tcphdr *th, __be32 *ptr, struct tcp_sock *tp,
 	 *  RM   |  C   |  C   |  C   |  P   |------|------|------|------|
 	 *  PRIO |  X   |  C   |  C   |  C   |  C   |------|------|------|
 	 *  FAIL |  X   |  X   |  C   |  X   |  X   |  X   |------|------|
-	 *  FC   |  X   |  X   |  X   |  X   |  X   |  X   |  X   |------|
+	 *  FC   |  X   |  X   |  P   |  X   |  X   |  X   |  X   |------|
 	 *  RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |
 	 * ------|------|------|------|------|------|------|------|------|
 	 *
diff --git a/net/mptcp/pm.c b/net/mptcp/pm.c
index 6afd39aea110a..64a1236aabee9 100644
--- a/net/mptcp/pm.c
+++ b/net/mptcp/pm.c
@@ -380,6 +380,7 @@ static void mptcp_pm_add_addr_timer(struct timer_list *timer)
 	struct mptcp_sock *msk = entry->sock;
 	struct sock *sk = (struct sock *)msk;
 	unsigned int timeout = 0;
+	bool retransmit;
 
 	pr_debug("msk=%p\n", msk);
 
@@ -412,14 +413,15 @@ static void mptcp_pm_add_addr_timer(struct timer_list *timer)
 		entry->retrans_times++;
 	}
 
-	if (entry->retrans_times < ADD_ADDR_RETRANS_MAX)
+	retransmit = entry->retrans_times < ADD_ADDR_RETRANS_MAX;
+	if (retransmit)
 		timeout <<= entry->retrans_times;
 	else
 		timeout = 0;
 
 	spin_unlock_bh(&msk->pm.lock);
 
-	if (entry->retrans_times == ADD_ADDR_RETRANS_MAX)
+	if (!retransmit)
 		mptcp_pm_subflow_established(msk);
 
 out:
@@ -441,6 +443,9 @@ bool mptcp_pm_announced_alloc(struct mptcp_sock *msk,
 
 	lockdep_assert_held(&msk->pm.lock);
 
+	if (msk->pm.status & BIT(MPTCP_PM_DESTROYING))
+		return false;
+
 	add_entry = mptcp_pm_announced_lookup(msk, addr);
 	if (add_entry) {
 		if (WARN_ON_ONCE(mptcp_pm_is_kernel(msk)))
@@ -1143,10 +1148,16 @@ void mptcp_pm_worker(struct mptcp_sock *msk)
 
 void mptcp_pm_destroy(struct mptcp_sock *msk)
 {
+	spin_lock_bh(&msk->pm.lock);
+	msk->pm.status |= BIT(MPTCP_PM_DESTROYING);
+	spin_unlock_bh(&msk->pm.lock);
+
 	mptcp_pm_free_announced_list(msk);
 
-	if (mptcp_pm_is_userspace(msk))
-		mptcp_userspace_pm_free_local_addr_list(msk);
+	/* Free the userspace local address list unconditionally: the socket
+	 * can be reused (mptcp_disconnect()) and re-selected to a different PM
+	 */
+	mptcp_userspace_pm_free_local_addr_list(msk);
 }
 
 void mptcp_pm_data_reset(struct mptcp_sock *msk)
diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
index 945aa5afc2ddf..2203cc2d27485 100644
--- a/net/mptcp/pm_userspace.c
+++ b/net/mptcp/pm_userspace.c
@@ -54,6 +54,10 @@ static int mptcp_userspace_pm_append_new_local_addr(struct mptcp_sock *msk,
 	bitmap_zero(id_bitmap, MPTCP_PM_MAX_ADDR_ID + 1);
 
 	spin_lock_bh(&msk->pm.lock);
+	if (msk->pm.status & BIT(MPTCP_PM_DESTROYING)) {
+		ret = -EINVAL;
+		goto append_err;
+	}
 	mptcp_for_each_userspace_pm_addr(msk, e) {
 		addr_match = mptcp_addresses_equal(&e->addr, &entry->addr, true);
 		if (addr_match && entry->addr.id == 0 && needs_id)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index ca644ec53eedb..7c8180d8d5eff 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -149,6 +149,12 @@ struct sock *__mptcp_nmpc_sk(struct mptcp_sock *msk)
 
 static void mptcp_drop(struct sock *sk, struct sk_buff *skb)
 {
+	/* The skb forward memory was already transferred to sk by
+	 * mptcp_borrow_fwdmem(), even before setting the destructor.
+	 */
+	if (!skb->destructor)
+		sk_mem_reclaim(sk);
+
 	sk_drops_skbadd(sk, skb);
 	__kfree_skb(skb);
 }
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 4a2d40cd7b132..1b80f2d6ec5a2 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -37,6 +37,7 @@
 				 OPTION_MPTCP_MPC_ACK)
 #define OPTIONS_MPTCP_MPJ	(OPTION_MPTCP_MPJ_SYN | OPTION_MPTCP_MPJ_SYNACK | \
 				 OPTION_MPTCP_MPJ_ACK)
+#define OPTIONS_MPTCP_DSS	(OPTION_MPTCP_DSS | OPTION_MPTCP_CSUMREQD)
 
 /* MPTCP option subtypes */
 #define MPTCPOPT_MP_CAPABLE	0
@@ -189,9 +190,10 @@ enum mptcp_pm_status {
 	MPTCP_PM_ESTABLISHED,
 	MPTCP_PM_SUBFLOW_ESTABLISHED,
 	MPTCP_PM_ALREADY_ESTABLISHED,	/* persistent status, set after ESTABLISHED event */
-	MPTCP_PM_MPC_ENDPOINT_ACCOUNTED /* persistent status, set after MPC local address is
-					 * accounted int id_avail_bitmap
-					 */
+	MPTCP_PM_MPC_ENDPOINT_ACCOUNTED, /* persistent status, set after MPC local address is
+					  * accounted int id_avail_bitmap
+					  */
+	MPTCP_PM_DESTROYING,		/* To fence out PM list allocs */
 };
 
 enum mptcp_pm_type {
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 8e386899ceb98..e1f20ff8fdb42 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -174,8 +174,6 @@ static int subflow_check_req(struct request_sock *req,
 
 		if (unlikely(listener->pm_listener))
 			return subflow_reset_req_endp(req, skb);
-		if (opt_mp_join)
-			return 0;
 	} else if (opt_mp_join) {
 		SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINSYNRX);
 
@@ -277,9 +275,6 @@ int mptcp_subflow_init_cookie_req(struct request_sock *req,
 
 	opt_mp_capable = !!(mp_opt.suboptions & OPTION_MPTCP_MPC_ACK);
 	opt_mp_join = !!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK);
-	if (opt_mp_capable && opt_mp_join)
-		return -EINVAL;
-
 	if (opt_mp_capable && listener->request_mptcp) {
 		if (mp_opt.sndr_key == 0)
 			return -EINVAL;
diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index c0aeffd5cb714..7dc91fac4917e 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -584,7 +584,7 @@ check_transfer()
 		mv "$tmpfile" "$out"
 		tmpfile=""
 	fi
-	cmp -l "$in" "$out" | while read -r i a b; do
+	while read -r i a b; do
 		local sum=$((0${a} + 0${b}))
 		if [ $check_invert -eq 0 ] || [ $sum -ne $((0xff)) ]; then
 			fail_test "$what does not match (in, out):"
@@ -595,7 +595,7 @@ check_transfer()
 		else
 			print_info "$what has inverted byte at ${i}"
 		fi
-	done
+	done < <(cmp -l "$in" "$out")
 
 	return 0
 }

gemini-3.1-pro-preview

null

null

							input: 6720
							output: 36
							thoughts: 939
						

**Analyzing the MPTCP Patch Series**

Okay, here's what I'm seeing with this patch series. We've got a set of modifications hitting key areas within the Linux kernel's MPTCP implementation, specifically in `net/mptcp/`. The files involved – `fastopen.c`, `options.c`, `pm.c`, `pm_userspace.c`, `protocol.c`, `subflow.c`, and even a test script, `mptcp_join.sh` – indicate pretty widespread changes.

Looking at `fastopen.c`, they've added a validity check for `skb` before marking a subflow as MPTCP Fast Open. Good practice – protecting against a potential null pointer dereference. The `WARN_ON_ONCE` removal is also a nice cleanup.

`options.c` is where things get interesting. They are adding explicit validation for different MPTCP option combinations. This is crucial for protocol robustness. So, making sure that `MPC_ACK` is paired with `RM_ADDR`, and similar constraints on `MP_JOIN`, `DSS`, `ADD_ADDR`, `RM_ADDR`, `MP_PRIO`, `MP_FASTCLOSE`, `RST`, and `MP_FAIL` are enforced. That's a solid defense against malformed packets. The comment change is probably a minor documentation tweak.

The changes in `pm.c` and `pm_userspace.c` address connection management. The addition of the `MPTCP_PM_DESTROYING` status flag is smart, clearly indicating when a path manager is in the process of being torn down. The bug fix in `mptcp_pm_add_addr_timer` for the retransmission timeout is important for reliability. Checking for that destroying flag and the unconditional call to `mptcp_userspace_pm_free_local_addr_list` in `mptcp_pm_destroy` and the checks in `mptcp_userspace_pm_append_new_local_addr` are all good for resource management.

In `protocol.c`, the added `sk_mem_reclaim` call in `mptcp_drop` before dropping the `skb` is a smart touch. That's a good approach to free resources, making sure we don't leak memory, which is always a risk with network stacks.

Finally, in `subflow.c`, the removal of the conditional checks involving `MP_JOIN` look like cleanups. They're probably fixing some logic that was either redundant or potentially causing issues in some scenarios.

Overall, this patch series is clearly aimed at hardening the MPTCP implementation. It's fixing bugs, adding much-needed option validation, and improving resource management around connection teardown.

My immediate thought is, *absolutely* this is worth fuzzing. MPTCP is core network protocol code, and any vulnerabilities here would be highly impactful.

Now, let's zero in on the key fuzzing targets. From what I've seen, `mptcp_parse_option` in `options.c` seems like a prime candidate, since it handles MPTCP option parsing. I need to dig into `net/mptcp/options.c` to understand how `mptcp_parse_option` is called to make a solid assessment of a target for fuzzing.

{
  "Expression": "mptcp_parse_option",
  "PathPrefix": "net/mptcp/options.c"
}

{
  "Output": "net/mptcp/options.c=18=static bool mptcp_cap_flag_sha256(u8 flags)\n--\nnet/mptcp/options.c-22-\nnet/mptcp/options.c:23:static void mptcp_parse_option(const struct sk_buff *skb,\nnet/mptcp/options.c-24-\t\t\t       const unsigned char *ptr, int opsize,\n--\nnet/mptcp/options.c=422=void mptcp_get_options(const struct sk_buff *skb,\n--\nnet/mptcp/options.c-456-\t\t\tif (opcode == TCPOPT_MPTCP)\nnet/mptcp/options.c:457:\t\t\t\tmptcp_parse_option(skb, ptr, opsize, mp_opt);\nnet/mptcp/options.c-458-\t\t\tptr += opsize - 2;\n"
}

gemini-3.1-pro-preview

null

null

							input: 8663
							output: 34
							thoughts: 183
						

**MPTCP Option Handling and PM Module Overview**

Okay, so I'm diving into this MPTCP code, trying to get a handle on how options are parsed and how the Path Management (PM) module works. From what I can see, `mptcp_get_options` is the key non-static function here. It's the entry point that, I'm assuming, is responsible for calling `mptcp_parse_option`, which is probably where the real decoding and processing of the MPTCP options happens. I need to trace the calling chain to understand the option negotiation process.

Looking at the `net/mptcp/pm.c` file, the PM module seems to have a few internal functions of interest. I see `mptcp_pm_add_addr_timer`, but it's static, so it's not directly accessible from outside. I might need to look at the surrounding code to see what that timer is doing – perhaps `mptcp_pm_announced_alloc` or `mptcp_pm_destroy` are related and have a clearer role in address management. These are the functions I'll need to focus on to get a handle on the PM's address management logic.

Then I noticed `mptcp_pm_announced_alloc` and `mptcp_pm_destroy` and they seem to have very clear roles as the names suggest.

The `net/mptcp/pm_userspace.c` file suggests that a userspace component also interacts with the PM module through `mptcp_userspace_pm_append_new_local_addr`, so there’s probably some coordination happening between the kernel and userspace on address allocation. I'll have to investigate that interaction carefully, as that's a key piece of the puzzle.

Finally, in `net/mptcp/protocol.c`, there's `mptcp_drop`. It's static, which limits its scope, so it's probably an internal error-handling function, but I need to see *who* is calling it to understand the circumstances under which an MPTCP connection might be dropped. The callsite information will give more insight.

{
  "Expression": "mptcp_drop",
  "PathPrefix": "net/mptcp/protocol.c"
}

{
  "Output": "net/mptcp/protocol.c=133=struct sock *__mptcp_nmpc_sk(struct mptcp_sock *msk)\n--\nnet/mptcp/protocol.c-149-\nnet/mptcp/protocol.c:150:static void mptcp_drop(struct sock *sk, struct sk_buff *skb)\nnet/mptcp/protocol.c-151-{\n--\nnet/mptcp/protocol.c=249=static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)\n--\nnet/mptcp/protocol.c-263-\t\t/* out of window */\nnet/mptcp/protocol.c:264:\t\tmptcp_drop(sk, skb);\nnet/mptcp/protocol.c-265-\t\tpr_debug(\"oow by %lld, rcv_wnd_sent %llu\\n\",\n--\nnet/mptcp/protocol.c-309-\t\t\t\t/* All the bits are present. Drop. */\nnet/mptcp/protocol.c:310:\t\t\t\tmptcp_drop(sk, skb);\nnet/mptcp/protocol.c-311-\t\t\t\tMPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);\n--\nnet/mptcp/protocol.c-325-\t\t\t\t\t\t\u0026msk-\u003eout_of_order_queue);\nnet/mptcp/protocol.c:326:\t\t\t\tmptcp_drop(sk, skb1);\nnet/mptcp/protocol.c-327-\t\t\t\tMPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);\n--\nnet/mptcp/protocol.c-347-\t\trb_erase(\u0026skb1-\u003erbnode, \u0026msk-\u003eout_of_order_queue);\nnet/mptcp/protocol.c:348:\t\tmptcp_drop(sk, skb1);\nnet/mptcp/protocol.c-349-\t\tMPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);\n--\nnet/mptcp/protocol.c=382=static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)\n--\nnet/mptcp/protocol.c-408-\t\tMPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);\nnet/mptcp/protocol.c:409:\t\tmptcp_drop(sk, skb);\nnet/mptcp/protocol.c-410-\t\treturn false;\n--\nnet/mptcp/protocol.c=793=static bool __mptcp_ofo_queue(struct mptcp_sock *msk)\n--\nnet/mptcp/protocol.c-812-\t\t\t\t      msk-\u003eack_seq))) {\nnet/mptcp/protocol.c:813:\t\t\tmptcp_drop(sk, skb);\nnet/mptcp/protocol.c-814-\t\t\tMPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_DUPDATA);\n"
}

gemini-3.1-pro-preview

null

null

							input: 10153
							output: 38
							thoughts: 58
						

Okay, let's see... I'm looking at `mptcp_drop`. It seems like this function is getting called from a few internal MPTCP functions: `mptcp_data_queue_ofo`, `__mptcp_move_skb`, and `__mptcp_ofo_queue`. Those names ring a bell; they look pretty deep within the MPTCP stack.

**Finding the Entry Points**

I need to figure out where the *external* calls to this function are originating. Since those listed are internal, they won't give me the full picture. My goal is to find the non-static entry points to better understand the overall data flow and how `mptcp_drop` is being triggered within the MPTCP context. I need to trace this function back to something I can understand.

{
  "Expression": "mptcp_data_queue_ofo",
  "PathPrefix": "net/mptcp/protocol.c"
}

{
  "Output": "net/mptcp/protocol.c=214=static bool mptcp_rcvbuf_grow(struct sock *sk, u32 newval)\n--\nnet/mptcp/protocol.c-248- */\nnet/mptcp/protocol.c:249:static void mptcp_data_queue_ofo(struct mptcp_sock *msk, struct sk_buff *skb)\nnet/mptcp/protocol.c-250-{\n--\nnet/mptcp/protocol.c=382=static bool __mptcp_move_skb(struct sock *sk, struct sk_buff *skb)\n--\nnet/mptcp/protocol.c-401-\t} else if (after64(MPTCP_SKB_CB(skb)-\u003emap_seq, msk-\u003eack_seq)) {\nnet/mptcp/protocol.c:402:\t\tmptcp_data_queue_ofo(msk, skb);\nnet/mptcp/protocol.c-403-\t\treturn false;\n"
}

gemini-3.1-pro-preview

null

null

							input: 10695
							output: 43
							thoughts: 30
						

Okay, here's my interpretation of that:

**My Perspective on `__mptcp_move_skb` and `__mptcp_move_skbs_from_subflow`**

Alright, so I'm thinking about the MPTCP stack and the intricacies of how packets move around. It's clear that `__mptcp_move_skb` is a critical function here. From what I understand, it's the workhorse, the thing that actually *does* the moving. And where is it being called from? The function, `__mptcp_move_skbs_from_subflow`. So, `__mptcp_move_skbs_from_subflow` is like the orchestrator, and it relies on `__mptcp_move_skb` to perform the actual movement of the socket buffers (SKBs). I need to dig deeper to see exactly what kind of movement we are talking about. Are we changing the subflow association of the skb, or its queue? It's essential to understand the logic behind why we are moving the skb, and the data structures involved, to really grasp the implications of this interaction. I can already see a potential for complexity here around synchronization and race conditions, as skb manipulation is often a source of subtle issues in network code. Need to verify that the locking strategy used around these functions is sufficient.

{
  "Expression": "__mptcp_move_skbs_from_subflow",
  "PathPrefix": "net/mptcp/protocol.c"
}

{
  "Output": "net/mptcp/protocol.c=676=static void __mptcp_add_backlog(struct sock *sk,\n--\nnet/mptcp/protocol.c-717-\nnet/mptcp/protocol.c:718:static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk,\nnet/mptcp/protocol.c-719-\t\t\t\t\t   struct sock *ssk, bool own_msk)\n--\nnet/mptcp/protocol.c=882=static bool move_skbs_to_msk(struct mptcp_sock *msk, struct sock *ssk)\n--\nnet/mptcp/protocol.c-886-\nnet/mptcp/protocol.c:887:\tmoved = __mptcp_move_skbs_from_subflow(msk, ssk, true);\nnet/mptcp/protocol.c-888-\t__mptcp_ofo_queue(msk);\n--\nnet/mptcp/protocol.c=928=void mptcp_data_ready(struct sock *sk, struct sock *ssk)\n--\nnet/mptcp/protocol.c-946-\t} else {\nnet/mptcp/protocol.c:947:\t\t__mptcp_move_skbs_from_subflow(msk, ssk, false);\nnet/mptcp/protocol.c-948-\t}\n"
}

gemini-3.1-pro-preview

null

null

							input: 11435
							output: 36
							thoughts: 133
						

**MPTCP Function Analysis**

Okay, let's zero in on `mptcp_data_ready`. It seems like a good non-static entry point to begin my assessment. I want to understand its role within the MPTCP framework.

Now, let me see... I recall a few functions in the codebase. Specifically, within `net/mptcp/fastopen.c`, I noticed `mptcp_fastopen_subflow_synack_set_params` is also non-static. Worth noting.

Then, there's `net/mptcp/subflow.c`. Here, I remember `subflow_check_req` is static, which is something I need to keep in mind, and `mptcp_subflow_init_cookie_req` is non-static.

Given the initial interest in `subflow_check_req`, I should probably start by reviewing the source code for `net/mptcp/subflow.c` itself. It’s likely to be most relevant.

{
  "Expression": "subflow_check_req",
  "PathPrefix": "net/mptcp/subflow.c"
}

{
  "Output": "net/mptcp/subflow.c=135=static int subflow_reset_req_endp(struct request_sock *req, struct sk_buff *skb)\n--\nnet/mptcp/subflow.c-146- */\nnet/mptcp/subflow.c:147:static int subflow_check_req(struct request_sock *req,\nnet/mptcp/subflow.c-148-\t\t\t     const struct sock *sk_listener,\n--\nnet/mptcp/subflow.c=311=static struct dst_entry *subflow_v4_route_req(const struct sock *sk,\n--\nnet/mptcp/subflow.c-326-\nnet/mptcp/subflow.c:327:\terr = subflow_check_req(req, sk, skb);\nnet/mptcp/subflow.c-328-\tif (err == 0)\n--\nnet/mptcp/subflow.c=380=static struct dst_entry *subflow_v6_route_req(const struct sock *sk,\n--\nnet/mptcp/subflow.c-395-\nnet/mptcp/subflow.c:396:\terr = subflow_check_req(req, sk, skb);\nnet/mptcp/subflow.c-397-\tif (err == 0)\n--\nnet/mptcp/subflow.c=2030=static void subflow_ulp_clone(const struct request_sock *req,\n--\nnet/mptcp/subflow.c-2078-\nnet/mptcp/subflow.c:2079:\t\t/* the subflow req id is valid, fetched via subflow_check_req()\nnet/mptcp/subflow.c-2080-\t\t * and subflow_token_join_request()\n"
}

gemini-3.1-pro-preview

null

null

							input: 12309
							output: 48
							thoughts: 180
						

**Analyzing MPTCP Route Requests and Path Management**

Okay, so I'm digging into this code and immediately I see `subflow_v4_route_req` and `subflow_v6_route_req` are static, which strongly suggests they're linked to something like `tcp_request_sock_ipv4_ops.route_req`. That's a good starting point, but I need to confirm the connections.

Next, I'll shift gears and look at the path management side within the MPTCP implementation. I'm going to quickly check `net/mptcp/pm.c` for those allocation and deallocation functions – I'm thinking about `mptcp_pm_announced_alloc` and `mptcp_pm_destroy`. Good, `mptcp_pm_announced_alloc` and `mptcp_pm_destroy` are both non-static. That likely means they're used outside their respective files, and are important.

Now, let's change direction again and peek into `net/mptcp/pm_userspace.c`. Specifically, I'm checking for `mptcp_userspace_pm_append_new_local_addr`. Ah, it's static. That likely means it's an internal helper function within that specific file. Okay, I've got a much better picture now.

{
  "Expression": "mptcp_userspace_pm_append_new_local_addr",
  "PathPrefix": "net/mptcp/pm_userspace.c"
}

{
  "Output": "net/mptcp/pm_userspace.c=31=mptcp_userspace_pm_lookup_addr(struct mptcp_sock *msk,\n--\nnet/mptcp/pm_userspace.c-42-\nnet/mptcp/pm_userspace.c:43:static int mptcp_userspace_pm_append_new_local_addr(struct mptcp_sock *msk,\nnet/mptcp/pm_userspace.c-44-\t\t\t\t\t\t    struct mptcp_pm_addr_entry *entry,\n--\nnet/mptcp/pm_userspace.c=133=int mptcp_userspace_pm_get_local_id(struct mptcp_sock *msk,\n--\nnet/mptcp/pm_userspace.c-151-\nnet/mptcp/pm_userspace.c:152:\treturn mptcp_userspace_pm_append_new_local_addr(msk, skc, true);\nnet/mptcp/pm_userspace.c-153-}\n--\nnet/mptcp/pm_userspace.c=194=int mptcp_pm_nl_announce_doit(struct sk_buff *skb, struct genl_info *info)\n--\nnet/mptcp/pm_userspace.c-227-\nnet/mptcp/pm_userspace.c:228:\terr = mptcp_userspace_pm_append_new_local_addr(msk, \u0026addr_val, false);\nnet/mptcp/pm_userspace.c-229-\tif (err \u003c 0) {\n--\nnet/mptcp/pm_userspace.c=364=int mptcp_pm_nl_subflow_create_doit(struct sk_buff *skb, struct genl_info *info)\n--\nnet/mptcp/pm_userspace.c-406-\nnet/mptcp/pm_userspace.c:407:\terr = mptcp_userspace_pm_append_new_local_addr(msk, \u0026entry, false);\nnet/mptcp/pm_userspace.c-408-\tif (err \u003c 0) {\n"
}

gemini-3.1-pro-preview

null

null

							input: 13399
							output: 32
							thoughts: 249
						

**MPTCP Symbol Identification**

Okay, let's see. My initial scan flagged a few functions as non-static: `mptcp_userspace_pm_get_local_id`, `mptcp_pm_nl_announce_doit`, and `mptcp_pm_nl_subflow_create_doit`. That's a good starting point. I should probably double-check `net/mptcp/options.c` to examine `mptcp_get_options`, since it could be related. Yep, it's also non-static, confirming that it's another key symbol.

Alright, with those in mind, I think these are the most likely symbols that might need to be understood in this context. I'm focusing on:

*   `mptcp_get_options`
*   `mptcp_fastopen_subflow_synack_set_params`
*   `mptcp_subflow_init_cookie_req`
*   `mptcp_pm_announced_alloc`
*   `mptcp_pm_destroy`
*   `mptcp_userspace_pm_get_local_id`
*   `mptcp_pm_nl_announce_doit`
*   `mptcp_pm_nl_subflow_create_doit`
*   `mptcp_data_ready`

It would be smart to start by checking the Kconfig options for MPTCP, just to have a high level understanding of how these bits all fit together.

{
  "Expression": "config MPTCP",
  "PathPrefix": "net/mptcp/Kconfig"
}

{
  "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: 14247
							output: 46
							thoughts: 466
						

**Analyzing MPTCP Configuration and Entry Points**

Okay, so I'm looking at this MPTCP configuration, and it seems like we're starting with `MPTCP`, and perhaps `MPTCP_IPV6` for IPv6 support would also be relevant. I should probably check if there are any other configuration dependencies. Ah, yes, `depends on INET` for MPTCP, that's important to remember.

Now, let's dive into the core symbols to pinpoint our modification entry points. I've identified a list: `mptcp_get_options`, `mptcp_fastopen_subflow_synack_set_params`, `mptcp_subflow_init_cookie_req`, `mptcp_pm_announced_alloc`, `mptcp_pm_destroy`, `mptcp_userspace_pm_get_local_id`, `mptcp_pm_nl_announce_doit`, and `mptcp_pm_nl_subflow_create_doit`, and finally, `mptcp_data_ready`. These seem like solid starting points for integrating the changes.

However, I need to be cautious about hot-path functions. `mptcp_get_options` is a bit concerning because it parses TCP options from the skb, meaning it's likely called on every received packet. That could be a performance bottleneck. I need to make sure I don't introduce any performance regressions. The actual changes in `mptcp_parse_option` are about validating combinations of MPTCP options. So `mptcp_get_options` is the only non-static caller, so there isn't another choice. We might just include that one, but I'll think about the others. `mptcp_data_ready` is also in the hot-path, since it is also called on every packet with data.

On balance, functions like `mptcp_fastopen_subflow_synack_set_params`, `mptcp_subflow_init_cookie_req`, `mptcp_pm_announced_alloc`, `mptcp_pm_destroy`, `mptcp_userspace_pm_get_local_id`, `mptcp_pm_nl_announce_doit`, and `mptcp_pm_nl_subflow_create_doit` seem less likely to be in the critical path and might be a better choice as starting points, given the nature of the changes.

I'll start by taking a look at `mptcp_fastopen_subflow_synack_set_params`, probably in `net/mptcp/fastopen.c`, to get a better sense of how things are structured.

{
  "Expression": "mptcp_fastopen_subflow_synack_set_params",
  "PathPrefix": "net/mptcp/fastopen.c"
}

{
  "Output": "net/mptcp/fastopen.c-8-\nnet/mptcp/fastopen.c:9:void mptcp_fastopen_subflow_synack_set_params(struct mptcp_subflow_context *subflow,\nnet/mptcp/fastopen.c-10-\t\t\t\t\t      struct request_sock *req)\n"
}

gemini-3.1-pro-preview

null

null

							input: 15449
							output: 42
							thoughts: 39
						

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

**Investigating Non-Static Behavior in MPTCP Subflow Initialization**

Right, this isn't behaving statically; I need to drill down. Let's see... the core issue likely lies in how the subflow cookie request is initialized. Specifically, I should examine `mptcp_subflow_init_cookie_req` within `net/mptcp/subflow.c`. That function holds the key to understanding how these subflow connections are being kicked off and why they might exhibit the dynamic behavior I'm observing. It’s the obvious starting point. I need to understand what's happening in there.

{
  "Expression": "mptcp_subflow_init_cookie_req",
  "PathPrefix": "net/mptcp/subflow.c"
}

{
  "Output": "net/mptcp/subflow.c=147=static int subflow_check_req(struct request_sock *req,\n--\nnet/mptcp/subflow.c-262-\nnet/mptcp/subflow.c:263:int mptcp_subflow_init_cookie_req(struct request_sock *req,\nnet/mptcp/subflow.c-264-\t\t\t\t  const struct sock *sk_listener,\n--\nnet/mptcp/subflow.c-298-}\nnet/mptcp/subflow.c:299:EXPORT_SYMBOL_GPL(mptcp_subflow_init_cookie_req);\nnet/mptcp/subflow.c-300-\n"
}

gemini-3.1-pro-preview

null

null

							input: 15878
							output: 38
							thoughts: 33
						

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

**Checking the Exported Symbol**

Alright, so I see it's exported. That's good; it means we should be able to get a handle on it without too much trouble. Now, let's dive into the guts of the Multipath TCP congestion control. I need to examine `mptcp_pm_announced_alloc`. I know it's probably in `net/mptcp/pm.c`. That's where all the good stuff lives. Let me go take a look and see what this announced allocation is all about. Hopefully, the code is well-commented...we'll see.

{
  "Expression": "mptcp_pm_announced_alloc",
  "PathPrefix": "net/mptcp/pm.c"
}

{
  "Output": "net/mptcp/pm.c=376=static void mptcp_pm_add_addr_timer(struct timer_list *timer)\n--\nnet/mptcp/pm.c-436-\nnet/mptcp/pm.c:437:bool mptcp_pm_announced_alloc(struct mptcp_sock *msk,\nnet/mptcp/pm.c-438-\t\t\t      const struct mptcp_addr_info *addr)\n"
}

gemini-3.1-pro-preview

null

null

							input: 16231
							output: 36
							thoughts: 33
						

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

**Investigating the Dynamic Nature of This Problem**

Hmm, this issue isn't static. It's behaving dynamically, which means a simple, fixed solution is unlikely. I need to understand the underlying mechanisms that are changing or interacting. This points toward potential issues in the connection management or even resource allocation.

Alright, a good starting point to investigate would be the MPTCP path manager destruction function. Let's see... I'll check `mptcp_pm_destroy` in `net/mptcp/pm.c`. That function should be responsible for cleaning up the path manager data structures. It's possible that there's a problem there, maybe a race condition or a memory leak that is causing the dynamic behavior. Let's see if this function is behaving as I would expect.

{
  "Expression": "mptcp_pm_destroy",
  "PathPrefix": "net/mptcp/pm.c"
}

{
  "Output": "net/mptcp/pm.c=1124=void mptcp_pm_worker(struct mptcp_sock *msk)\n--\nnet/mptcp/pm.c-1148-\nnet/mptcp/pm.c:1149:void mptcp_pm_destroy(struct mptcp_sock *msk)\nnet/mptcp/pm.c-1150-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 16604
							output: 46
							thoughts: 43
						

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

**Analyzing the Dynamic Nature**

Right, this feels like it's inherently *non-static*. That immediately triggers some questions about how we're handling identifiers. Let's dig deeper into the MPTCP userspace PM implementation to see what's happening. My immediate port of call is to check `mptcp_userspace_pm_get_local_id` within `net/mptcp/pm_userspace.c`. That function will likely shed some light on how local identifiers are assigned and managed in this particular context. This is the natural entry point to understand how the system is behaving in its current state.

{
  "Expression": "mptcp_userspace_pm_get_local_id",
  "PathPrefix": "net/mptcp/pm_userspace.c"
}

{
  "Output": "net/mptcp/pm_userspace.c=122=mptcp_userspace_pm_lookup_addr_by_id(struct mptcp_sock *msk, unsigned int id)\n--\nnet/mptcp/pm_userspace.c-132-\nnet/mptcp/pm_userspace.c:133:int mptcp_userspace_pm_get_local_id(struct mptcp_sock *msk,\nnet/mptcp/pm_userspace.c-134-\t\t\t\t    struct mptcp_pm_addr_entry *skc)\n"
}

gemini-3.1-pro-preview

null

null

							input: 17001
							output: 44
							thoughts: 41
						

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

**Investigating a Potentially Dynamic MPTCP Issue**

Right, this feels like it's *not* a static problem. That's a key clue. If it were static, I'd have a much more straightforward path. But since it isn't, I need to dig deeper into the more dynamic parts of the system. I suspect the issue lies in something that's changing over time.

Okay, where to start... let's cut right to the chase. Given the non-static nature of this situation, I'm going to jump straight into the userspace interaction within MPTCP. My gut says it has something to do with how the user-space daemon is interacting with the kernel. I'm going to examine `mptcp_pm_nl_announce_doit` in `net/mptcp/pm_userspace.c`. That function handles the announcement and management of path management information with userspace. It's a prime suspect for an issue that might manifest dynamically during the negotiation or active use of MPTCP paths. I need to understand how the path manager is announcing the path information to the user-space daemon and then how this is being acted upon. Let's see what's happening.

{
  "Expression": "mptcp_pm_nl_announce_doit",
  "PathPrefix": "net/mptcp/pm_userspace.c"
}

{
  "Output": "net/mptcp/pm_userspace.c=169=static struct mptcp_sock *mptcp_userspace_pm_get_sock(const struct genl_info *info)\n--\nnet/mptcp/pm_userspace.c-193-\nnet/mptcp/pm_userspace.c:194:int mptcp_pm_nl_announce_doit(struct sk_buff *skb, struct genl_info *info)\nnet/mptcp/pm_userspace.c-195-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 17515
							output: 47
							thoughts: 44
						

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

**Investigating Non-Static Behavior in MPTCP**

Alright, this isn't static. That tells me I need to dig deeper into the dynamic aspects of this issue. Let's see... since we're dealing with MPTCP and it's behaving non-statically, my initial thought is to look at the process of creating subflows. That's a good place to start, especially when things aren't behaving predictably.

Let me take a look at `net/mptcp/pm_userspace.c`, specifically the function `mptcp_pm_nl_subflow_create_doit`. That's where I would expect to find the logic responsible for handling userspace-initiated subflow creation requests. This is the code that orchestrates the actions that might lead to something not being static. This function is the best first point to check. I need to understand how the system is behaving when trying to create a subflow. Let's see what's happening there... I'll check its interaction with the other parts of the MPTCP stack, especially any state changes or configurations that could influence dynamic behavior.

{
  "Expression": "mptcp_pm_nl_subflow_create_doit",
  "PathPrefix": "net/mptcp/pm_userspace.c"
}

{
  "Output": "net/mptcp/pm_userspace.c=304=int mptcp_pm_nl_remove_doit(struct sk_buff *skb, struct genl_info *info)\n--\nnet/mptcp/pm_userspace.c-363-\nnet/mptcp/pm_userspace.c:364:int mptcp_pm_nl_subflow_create_doit(struct sk_buff *skb, struct genl_info *info)\nnet/mptcp/pm_userspace.c-365-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 18018
							output: 178
							thoughts: 201
						

**My Fuzzing Strategy: MPTCP Focus**

Okay, here's what I'm thinking. This target is *dynamic*; it's not a static, unchanging piece of code. It's got legs, and that means fuzzing is going to reveal interesting vulnerabilities.

The core configuration I need to set up is, without a doubt, `MPTCP`. That's the foundation we're building on.

Now, let's nail down this final response. The `WorthFuzzing` flag is set to `true` – absolutely, this is a prime target! We are definitely going to fuzz this.

My specific areas of concentration, the critical symbols I *need* to focus on, are these:

*   `mptcp_fastopen_subflow_synack_set_params` - Crucial for Fast Open setup, always a juicy target
*   `mptcp_subflow_init_cookie_req` - Cookie Requests, another important function in subflow
*   `mptcp_pm_announced_alloc` - Handling PM allocation, will be fruitful
*   `mptcp_pm_destroy` - PM destruction, could be a memory playground
*   `mptcp_userspace_pm_get_local_id` - Important function to get the local ID
*   `mptcp_pm_nl_announce_doit` - This looks important too.
*   `mptcp_pm_nl_subflow_create_doit` - NL Subflow creates are very important.

And, of course, the `EnableConfigs` list confirms the setup: I need `MPTCP` enabled.

The reasoning is clear: this patch series introduces functional changes directly affecting the MPTCP protocol implementation. We're talking about core networking features – specifically, option validation, memory reclamation, and the handling of PM destruction. These are precisely the types of functionalities that are *begging* to be fuzzed. It's where the interesting vulnerabilities are most likely to hide.

{
  "EnableConfigs": [
    "MPTCP"
  ],
  "FocusSymbols": [
    "mptcp_fastopen_subflow_synack_set_params",
    "mptcp_subflow_init_cookie_req",
    "mptcp_pm_announced_alloc",
    "mptcp_pm_destroy",
    "mptcp_userspace_pm_get_local_id",
    "mptcp_pm_nl_announce_doit",
    "mptcp_pm_nl_subflow_create_doit"
  ],
  "Reasoning": "The patch series makes functional changes to the MPTCP protocol implementation, including option validation, memory reclamation, and PM destruction handling. These are core networking features that should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MPTCP"
  ],
  "FocusSymbols": [
    "mptcp_fastopen_subflow_synack_set_params",
    "mptcp_subflow_init_cookie_req",
    "mptcp_pm_announced_alloc",
    "mptcp_pm_destroy",
    "mptcp_userspace_pm_get_local_id",
    "mptcp_pm_nl_announce_doit",
    "mptcp_pm_nl_subflow_create_doit"
  ],
  "Reasoning": "The patch series makes functional changes to the MPTCP protocol implementation, including option validation, memory reclamation, and PM destruction handling. These are core networking features that should be fuzzed.",
  "WorthFuzzing": true
}