| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/08/24 09:07 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": [
"IP_SCTP"
],
"FocusSymbols": [
"sctp_process_strreset_addstrm_in",
"sctp_process_strreset_addstrm_out",
"sctp_process_strreset_inreq",
"sctp_process_strreset_outreq",
"sctp_process_strreset_resp",
"sctp_send_add_streams",
"sctp_send_reset_assoc",
"sctp_send_reset_streams"
],
"KMSANReasoning": "The patch changes the tracking of outstanding SCTP stream reset requests from a simple counter to a bitmask. It modifies internal state tracking logic in `struct sctp_association` and does not introduce any new data structures, allocations, or data copied to user space. There is no risk of uninitialized memory reads or info-leaks exposed by these changes. Standard KASAN and other bug detectors are sufficient to catch any memory corruption or out-of-bounds accesses related to this code.",
"NeedsKMSAN": false,
"Reasoning": "The patch modifies the SCTP stream reset logic, changing `strreset_outstanding` from a counter to a bitmask and updating the corresponding send and process functions. This is a functional change in a core networking protocol that is reachable and should be fuzzed.",
"WorthFuzzing": true
} |
| 1/1 | 2026/08/24 09:07 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 186785661f91b6bd34fdd06aa413b2f147299e53\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Aug 24 09:07:19 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h\nindex cccc662561aac..b21f23b736fd2 100644\n--- a/include/net/sctp/structs.h\n+++ b/include/net/sctp/structs.h\n@@ -2057,7 +2057,7 @@ struct sctp_association {\n \t force_delay:1;\n \n \t__u8 strreset_enable;\n-\t__u8 strreset_outstanding; /* request param count on the fly */\n+\t__u8 strreset_outstanding; /* request param bitmask on the fly */\n \n \t__u32 strreset_outseq; /* Update after receiving response */\n \t__u32 strreset_inseq; /* Update after receiving request */\ndiff --git a/net/sctp/stream.c b/net/sctp/stream.c\nindex 34ffe6c945a4b..9fee0da78845c 100644\n--- a/net/sctp/stream.c\n+++ b/net/sctp/stream.c\n@@ -22,6 +22,15 @@\n #include \u003cnet/sctp/sm.h\u003e\n #include \u003cnet/sctp/stream_sched.h\u003e\n \n+#define SCTP_STRRESET_MASK(type) \\\n+\tBIT(ntohs(type) - ntohs(SCTP_PARAM_RESET_OUT_REQUEST))\n+#define SCTP_STRRESET_TEST(asoc, type) \\\n+\t((asoc)-\u003estrreset_outstanding \u0026 SCTP_STRRESET_MASK(type))\n+#define SCTP_STRRESET_SET(asoc, type) \\\n+\t((asoc)-\u003estrreset_outstanding |= SCTP_STRRESET_MASK(type))\n+#define SCTP_STRRESET_CLEAR(asoc, type) \\\n+\t((asoc)-\u003estrreset_outstanding \u0026= ~SCTP_STRRESET_MASK(type))\n+\n static void sctp_stream_shrink_out(struct sctp_stream *stream, __u16 outcnt)\n {\n \tstruct sctp_association *asoc;\n@@ -372,7 +381,10 @@ int sctp_send_reset_streams(struct sctp_association *asoc,\n \t\tgoto out;\n \t}\n \n-\tasoc-\u003estrreset_outstanding = out + in;\n+\tif (out)\n+\t\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);\n+\tif (in)\n+\t\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_IN_REQUEST);\n \n out:\n \treturn retval;\n@@ -417,7 +429,7 @@ int sctp_send_reset_assoc(struct sctp_association *asoc)\n \t\treturn retval;\n \t}\n \n-\tasoc-\u003estrreset_outstanding = 1;\n+\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_TSN_REQUEST);\n \n \treturn 0;\n }\n@@ -474,7 +486,10 @@ int sctp_send_add_streams(struct sctp_association *asoc,\n \t\tgoto out;\n \t}\n \n-\tasoc-\u003estrreset_outstanding = !!out + !!in;\n+\tif (out)\n+\t\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);\n+\tif (in)\n+\t\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);\n \n out:\n \treturn retval;\n@@ -482,7 +497,7 @@ int sctp_send_add_streams(struct sctp_association *asoc,\n \n static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(\n \t\t\tstruct sctp_association *asoc, __be32 resp_seq,\n-\t\t\t__be16 type)\n+\t\t\t__be16 type, bool match_seq)\n {\n \tstruct sctp_chunk *chunk = asoc-\u003estrreset_chunk;\n \tstruct sctp_reconf_chunk *hdr;\n@@ -499,7 +514,7 @@ static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(\n \t\t */\n \t\tstruct sctp_strreset_tsnreq *req = param.v;\n \n-\t\tif ((!resp_seq || req-\u003erequest_seq == resp_seq) \u0026\u0026\n+\t\tif ((!match_seq || req-\u003erequest_seq == resp_seq) \u0026\u0026\n \t\t (!type || type == req-\u003eparam_hdr.type))\n \t\t\treturn param.v;\n \t}\n@@ -564,13 +579,14 @@ struct sctp_chunk *sctp_process_strreset_outreq(\n \tif (asoc-\u003estrreset_chunk) {\n \t\tif (!sctp_chunk_lookup_strreset_param(\n \t\t\t\tasoc, outreq-\u003eresponse_seq,\n-\t\t\t\tSCTP_PARAM_RESET_IN_REQUEST)) {\n+\t\t\t\tSCTP_PARAM_RESET_IN_REQUEST, true) ||\n+\t\t !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_IN_REQUEST)) {\n \t\t\t/* same process with outstanding isn't 0 */\n \t\t\tresult = SCTP_STRRESET_ERR_IN_PROGRESS;\n \t\t\tgoto out;\n \t\t}\n \n-\t\tasoc-\u003estrreset_outstanding--;\n+\t\tSCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_IN_REQUEST);\n \t\tasoc-\u003estrreset_outseq++;\n \n \t\tif (!asoc-\u003estrreset_outstanding) {\n@@ -669,7 +685,7 @@ struct sctp_chunk *sctp_process_strreset_inreq(\n \t\t\tSCTP_SO(stream, i)-\u003estate = SCTP_STREAM_CLOSED;\n \n \tasoc-\u003estrreset_chunk = chunk;\n-\tasoc-\u003estrreset_outstanding = 1;\n+\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);\n \tsctp_chunk_hold(asoc-\u003estrreset_chunk);\n \n \tresult = SCTP_STRRESET_PERFORMED;\n@@ -816,13 +832,14 @@ struct sctp_chunk *sctp_process_strreset_addstrm_out(\n \n \tif (asoc-\u003estrreset_chunk) {\n \t\tif (!sctp_chunk_lookup_strreset_param(\n-\t\t\tasoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {\n+\t\t\tasoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS, false) ||\n+\t\t !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {\n \t\t\t/* same process with outstanding isn't 0 */\n \t\t\tresult = SCTP_STRRESET_ERR_IN_PROGRESS;\n \t\t\tgoto out;\n \t\t}\n \n-\t\tasoc-\u003estrreset_outstanding--;\n+\t\tSCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);\n \t\tasoc-\u003estrreset_outseq++;\n \n \t\tif (!asoc-\u003estrreset_outstanding) {\n@@ -899,7 +916,7 @@ struct sctp_chunk *sctp_process_strreset_addstrm_in(\n \t\tgoto out;\n \n \tasoc-\u003estrreset_chunk = chunk;\n-\tasoc-\u003estrreset_outstanding = 1;\n+\tSCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);\n \tsctp_chunk_hold(asoc-\u003estrreset_chunk);\n \n \tstream-\u003eoutcnt = outcnt;\n@@ -927,8 +944,9 @@ struct sctp_chunk *sctp_process_strreset_resp(\n \tstruct sctp_paramhdr *req;\n \t__u32 result;\n \n-\treq = sctp_chunk_lookup_strreset_param(asoc, resp-\u003eresponse_seq, 0);\n-\tif (!req)\n+\treq = sctp_chunk_lookup_strreset_param(asoc, resp-\u003eresponse_seq, 0,\n+\t\t\t\t\t true);\n+\tif (!req || !SCTP_STRRESET_TEST(asoc, req-\u003etype))\n \t\treturn NULL;\n \n \tresult = ntohl(resp-\u003eresult);\n@@ -1078,7 +1096,7 @@ struct sctp_chunk *sctp_process_strreset_resp(\n \t\t\tnums, 0, GFP_ATOMIC);\n \t}\n \n-\tasoc-\u003estrreset_outstanding--;\n+\tSCTP_STRRESET_CLEAR(asoc, req-\u003etype);\n \tasoc-\u003estrreset_outseq++;\n \n \t/* remove everything for this reconf request */\n"
} |
| 2/1 | 2026/08/24 09:07 | agent | patch-evaluator |
0mModel:best-expensive Args: null Results: {
"EnableConfigs": [
"IP_SCTP"
],
"FocusSymbols": [
"sctp_process_strreset_addstrm_in",
"sctp_process_strreset_addstrm_out",
"sctp_process_strreset_inreq",
"sctp_process_strreset_outreq",
"sctp_process_strreset_resp",
"sctp_send_add_streams",
"sctp_send_reset_assoc",
"sctp_send_reset_streams"
],
"Reasoning": "The patch modifies the SCTP stream reset logic, changing `strreset_outstanding` from a counter to a bitmask and updating the corresponding send and process functions. This is a functional change in a core networking protocol that is reachable and should be fuzzed.",
"WorthFuzzing": true
}Instruction: 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. Prompt: For your convenience, here is the diff of the changes:
commit 186785661f91b6bd34fdd06aa413b2f147299e53
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Aug 24 09:07:19 2026 +0000
syz-cluster: applied patch under review
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index cccc662561aac..b21f23b736fd2 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -2057,7 +2057,7 @@ struct sctp_association {
force_delay:1;
__u8 strreset_enable;
- __u8 strreset_outstanding; /* request param count on the fly */
+ __u8 strreset_outstanding; /* request param bitmask on the fly */
__u32 strreset_outseq; /* Update after receiving response */
__u32 strreset_inseq; /* Update after receiving request */
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 34ffe6c945a4b..9fee0da78845c 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -22,6 +22,15 @@
#include <net/sctp/sm.h>
#include <net/sctp/stream_sched.h>
+#define SCTP_STRRESET_MASK(type) \
+ BIT(ntohs(type) - ntohs(SCTP_PARAM_RESET_OUT_REQUEST))
+#define SCTP_STRRESET_TEST(asoc, type) \
+ ((asoc)->strreset_outstanding & SCTP_STRRESET_MASK(type))
+#define SCTP_STRRESET_SET(asoc, type) \
+ ((asoc)->strreset_outstanding |= SCTP_STRRESET_MASK(type))
+#define SCTP_STRRESET_CLEAR(asoc, type) \
+ ((asoc)->strreset_outstanding &= ~SCTP_STRRESET_MASK(type))
+
static void sctp_stream_shrink_out(struct sctp_stream *stream, __u16 outcnt)
{
struct sctp_association *asoc;
@@ -372,7 +381,10 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
goto out;
}
- asoc->strreset_outstanding = out + in;
+ if (out)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);
+ if (in)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_IN_REQUEST);
out:
return retval;
@@ -417,7 +429,7 @@ int sctp_send_reset_assoc(struct sctp_association *asoc)
return retval;
}
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_TSN_REQUEST);
return 0;
}
@@ -474,7 +486,10 @@ int sctp_send_add_streams(struct sctp_association *asoc,
goto out;
}
- asoc->strreset_outstanding = !!out + !!in;
+ if (out)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);
+ if (in)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);
out:
return retval;
@@ -482,7 +497,7 @@ int sctp_send_add_streams(struct sctp_association *asoc,
static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(
struct sctp_association *asoc, __be32 resp_seq,
- __be16 type)
+ __be16 type, bool match_seq)
{
struct sctp_chunk *chunk = asoc->strreset_chunk;
struct sctp_reconf_chunk *hdr;
@@ -499,7 +514,7 @@ static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(
*/
struct sctp_strreset_tsnreq *req = param.v;
- if ((!resp_seq || req->request_seq == resp_seq) &&
+ if ((!match_seq || req->request_seq == resp_seq) &&
(!type || type == req->param_hdr.type))
return param.v;
}
@@ -564,13 +579,14 @@ struct sctp_chunk *sctp_process_strreset_outreq(
if (asoc->strreset_chunk) {
if (!sctp_chunk_lookup_strreset_param(
asoc, outreq->response_seq,
- SCTP_PARAM_RESET_IN_REQUEST)) {
+ SCTP_PARAM_RESET_IN_REQUEST, true) ||
+ !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_IN_REQUEST)) {
/* same process with outstanding isn't 0 */
result = SCTP_STRRESET_ERR_IN_PROGRESS;
goto out;
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_IN_REQUEST);
asoc->strreset_outseq++;
if (!asoc->strreset_outstanding) {
@@ -669,7 +685,7 @@ struct sctp_chunk *sctp_process_strreset_inreq(
SCTP_SO(stream, i)->state = SCTP_STREAM_CLOSED;
asoc->strreset_chunk = chunk;
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);
sctp_chunk_hold(asoc->strreset_chunk);
result = SCTP_STRRESET_PERFORMED;
@@ -816,13 +832,14 @@ struct sctp_chunk *sctp_process_strreset_addstrm_out(
if (asoc->strreset_chunk) {
if (!sctp_chunk_lookup_strreset_param(
- asoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {
+ asoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS, false) ||
+ !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {
/* same process with outstanding isn't 0 */
result = SCTP_STRRESET_ERR_IN_PROGRESS;
goto out;
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);
asoc->strreset_outseq++;
if (!asoc->strreset_outstanding) {
@@ -899,7 +916,7 @@ struct sctp_chunk *sctp_process_strreset_addstrm_in(
goto out;
asoc->strreset_chunk = chunk;
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);
sctp_chunk_hold(asoc->strreset_chunk);
stream->outcnt = outcnt;
@@ -927,8 +944,9 @@ struct sctp_chunk *sctp_process_strreset_resp(
struct sctp_paramhdr *req;
__u32 result;
- req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0);
- if (!req)
+ req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0,
+ true);
+ if (!req || !SCTP_STRRESET_TEST(asoc, req->type))
return NULL;
result = ntohl(resp->result);
@@ -1078,7 +1096,7 @@ struct sctp_chunk *sctp_process_strreset_resp(
nums, 0, GFP_ATOMIC);
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, req->type);
asoc->strreset_outseq++;
/* remove everything for this reconf request */
|
| 3/2 | 2026/08/24 09:07 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4094 output: 34 thoughts: 240 Thoughts: **Analyzing a Patch for SCTP Stream Reset Logic** Okay, so I've got this patch in front of me that's making some pretty fundamental changes to SCTP's stream reset logic. It looks like the main thrust is switching `strreset_outstanding` from a simple count to a bitmask. Smart move, potentially; bitmasks offer more granular control and can be more efficient in certain scenarios. I'm seeing changes to `include/net/sctp/structs.h` and `net/sctp/stream.c`, which is what I'd expect given the nature of the modification. The introduction of those macros – `SCTP_STRRESET_MASK`, `SCTP_STRRESET_TEST`, `SCTP_STRRESET_SET`, and `SCTP_STRRESET_CLEAR` – are key; they'll handle the bitwise operations in a cleaner, more readable, and potentially less error-prone way. Replacing that direct assignment, `asoc->strreset_outstanding = out + in;`, with bitmask operations further confirms the change in approach. And the modification to `sctp_chunk_lookup_strreset_param` to accept a `match_seq` boolean is interesting; I'll need to dig into that function to understand the implications of that change. The next question, as always, is whether this area is something we should be focusing on for fuzzing. SCTP's a core networking protocol, so it's *definitely* reachable; that's not even a question. Any code in that space is ripe for fuzzing. Now, let's find the relevant configuration options. `CONFIG_IP_SCTP` is the obvious starting point. I'll do a quick `grep` in `net/sctp/Kconfig` to confirm that and to identify any other potentially relevant configurations. Gotta make sure we've got the right settings to actually trigger this code. This patch looks promising. |
| 4/2 | 2026/08/24 09:07 | tool | grepper |
0mArgs:{
"Expression": "config IP_SCTP",
"PathPrefix": "net/sctp/Kconfig"
}Results: {
"Output": "net/sctp/Kconfig-5-\nnet/sctp/Kconfig:6:menuconfig IP_SCTP\nnet/sctp/Kconfig-7-\ttristate \"The SCTP Protocol\"\n"
} |
| 5/2 | 2026/08/24 09:07 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4856 output: 123 thoughts: 184 Thoughts: **Analyzing SCTP Stream Reset Functionality** Okay, so I'm looking at the `IP_SCTP` configuration and need to understand the recent modifications. My primary focus is on the `net/sctp/stream.c` file. Right, let's list those functions: `sctp_send_reset_streams`, `sctp_send_reset_assoc`, `sctp_send_add_streams`, `sctp_chunk_lookup_strreset_param` (that one's likely static, but good to note), `sctp_process_strreset_outreq`, `sctp_process_strreset_inreq`, `sctp_process_strreset_addstrm_out`, `sctp_process_strreset_addstrm_in`, and finally `sctp_process_strreset_resp`. Now, I need to quickly determine the scope of these; whether they are static within the file or whether they are exported or global functions, since the latter would have implications for other parts of the system. I need to understand how the stream reset mechanism is implemented and how it interacts with the rest of the SCTP stack. |
| 6/2 | 2026/08/24 09:07 | tool | grepper |
0mArgs:{
"Expression": "sctp_send_reset_streams|sctp_send_reset_assoc|sctp_send_add_streams|sctp_process_strreset_outreq|sctp_process_strreset_inreq|sctp_process_strreset_addstrm_out|sctp_process_strreset_addstrm_in|sctp_process_strreset_resp",
"PathPrefix": "net/sctp/stream.c"
}Results: {
"Output": "net/sctp/stream.c=250=static bool sctp_stream_outq_is_empty(struct sctp_stream *stream,\n--\nnet/sctp/stream.c-273-\nnet/sctp/stream.c:274:int sctp_send_reset_streams(struct sctp_association *asoc,\nnet/sctp/stream.c-275-\t\t\t struct sctp_reset_streams *params)\n--\nnet/sctp/stream.c-392-\nnet/sctp/stream.c:393:int sctp_send_reset_assoc(struct sctp_association *asoc)\nnet/sctp/stream.c-394-{\n--\nnet/sctp/stream.c-436-\nnet/sctp/stream.c:437:int sctp_send_add_streams(struct sctp_association *asoc,\nnet/sctp/stream.c-438-\t\t\t struct sctp_add_streams *params)\n--\nnet/sctp/stream.c=525=static void sctp_update_strreset_result(struct sctp_association *asoc,\n--\nnet/sctp/stream.c-531-\nnet/sctp/stream.c:532:struct sctp_chunk *sctp_process_strreset_outreq(\nnet/sctp/stream.c-533-\t\t\t\tstruct sctp_association *asoc,\n--\nnet/sctp/stream.c-621-\nnet/sctp/stream.c:622:struct sctp_chunk *sctp_process_strreset_inreq(\nnet/sctp/stream.c-623-\t\t\t\tstruct sctp_association *asoc,\n--\nnet/sctp/stream.c=702=struct sctp_chunk *sctp_process_strreset_tsnreq(\n--\nnet/sctp/stream.c-798-\nnet/sctp/stream.c:799:struct sctp_chunk *sctp_process_strreset_addstrm_out(\nnet/sctp/stream.c-800-\t\t\t\tstruct sctp_association *asoc,\n--\nnet/sctp/stream.c-869-\nnet/sctp/stream.c:870:struct sctp_chunk *sctp_process_strreset_addstrm_in(\nnet/sctp/stream.c-871-\t\t\t\tstruct sctp_association *asoc,\n--\nnet/sctp/stream.c-934-\nnet/sctp/stream.c:935:struct sctp_chunk *sctp_process_strreset_resp(\nnet/sctp/stream.c-936-\t\t\t\tstruct sctp_association *asoc,\n"
} |
| 7/2 | 2026/08/24 09:07 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 6172 output: 30 thoughts: 240 Thoughts: **SCTP Stream Reset Functionality for Fuzzing** Okay, so I've been looking at these SCTP functions, and the key takeaway is that they all deal with stream reset functionality. It's a functional change, a fix or a behavior change, specifically related to the RE-CONFIG chunk within the SCTP protocol, and it's all non-static *except* for `sctp_chunk_lookup_strreset_param`, which I'm skipping. This screams "potential for fuzzing". We're talking about core protocol handling, so let's get down to brass tacks and figure out what we need to focus on. Here's the list of functions that seem most relevant to the stream reset process: * `sctp_send_reset_streams` * `sctp_send_reset_assoc` * `sctp_send_add_streams` * `sctp_process_strreset_outreq` * `sctp_process_strreset_inreq` * `sctp_process_strreset_addstrm_out` * `sctp_process_strreset_addstrm_in` * `sctp_process_strreset_resp` And the key configuration to keep in mind is `IP_SCTP`. I'll need to double check, just to be thorough, if any other configurations might be relevant for SCTP. You never know what dependencies might come into play when fuzzing. |
| 8/2 | 2026/08/24 09:07 | tool | grepper |
0mArgs:{
"Expression": "depends on",
"PathPrefix": "net/sctp/Kconfig"
}Results: {
"Output": "net/sctp/Kconfig=6=menuconfig IP_SCTP\nnet/sctp/Kconfig-7-\ttristate \"The SCTP Protocol\"\nnet/sctp/Kconfig:8:\tdepends on INET\nnet/sctp/Kconfig-9-\tselect CRYPTO_LIB_SHA1\n--\nnet/sctp/Kconfig=41=config SCTP_DBG_OBJCNT\nnet/sctp/Kconfig-42-\tbool \"SCTP: Debug object counts\"\nnet/sctp/Kconfig:43:\tdepends on PROC_FS\nnet/sctp/Kconfig-44-\thelp\n--\nnet/sctp/Kconfig=70=config INET_SCTP_DIAG\nnet/sctp/Kconfig:71:\tdepends on INET_DIAG\nnet/sctp/Kconfig-72-\tdef_tristate INET_DIAG\n"
} |
| 9/2 | 2026/08/24 09:07 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7023 output: 201 thoughts: 241 Thoughts: **My Assessment of the SCTP Stream Reset Patch** Okay, so we're looking at a standard `INET` configuration, and `IP_SCTP` is clearly going to be sufficient for this. My initial thought is to quickly verify if the `sctp_process_strreset_tsnreq` function was touched by this patch, just to be sure. Nope, it wasn't. Now, let's formulate a response. Given the changes, this definitely warrants fuzzing. The `WorthFuzzing: true` flag is appropriate. The focus should be on these key symbols: `sctp_send_reset_streams`, `sctp_send_reset_assoc`, `sctp_send_add_streams`, `sctp_process_strreset_outreq`, `sctp_process_strreset_inreq`, `sctp_process_strreset_addstrm_out`, `sctp_process_strreset_addstrm_in`, and `sctp_process_strreset_resp`. Why these functions? Because the patch fundamentally changes the SCTP stream reset logic, converting `strreset_outstanding` from a simple counter to a bitmask. And that's a big deal. The send and process functions related to this are updated as a result. This is a functional change deep within a core networking protocol. It’s definitely reachable, making it a prime target for fuzzing. The `EnableConfigs` setting should obviously include `IP_SCTP` to run our fuzzing appropriately. |
| 10/2 | 2026/08/24 09:07 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"IP_SCTP"
],
"FocusSymbols": [
"sctp_process_strreset_addstrm_in",
"sctp_process_strreset_addstrm_out",
"sctp_process_strreset_inreq",
"sctp_process_strreset_outreq",
"sctp_process_strreset_resp",
"sctp_send_add_streams",
"sctp_send_reset_assoc",
"sctp_send_reset_streams"
],
"Reasoning": "The patch modifies the SCTP stream reset logic, changing `strreset_outstanding` from a counter to a bitmask and updating the corresponding send and process functions. This is a functional change in a core networking protocol that is reachable and should be fuzzed.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"IP_SCTP"
],
"FocusSymbols": [
"sctp_process_strreset_addstrm_in",
"sctp_process_strreset_addstrm_out",
"sctp_process_strreset_inreq",
"sctp_process_strreset_outreq",
"sctp_process_strreset_resp",
"sctp_send_add_streams",
"sctp_send_reset_assoc",
"sctp_send_reset_streams"
],
"Reasoning": "The patch modifies the SCTP stream reset logic, changing `strreset_outstanding` from a counter to a bitmask and updating the corresponding send and process functions. This is a functional change in a core networking protocol that is reachable and should be fuzzed.",
"WorthFuzzing": true
} |
| 11/1 | 2026/08/24 09:07 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 12/2 | 2026/08/24 09:07 | agent | kmsan-evaluator |
0mModel:best-expensive Args: null Results: {
"KMSANReasoning": "The patch changes the tracking of outstanding SCTP stream reset requests from a simple counter to a bitmask. It modifies internal state tracking logic in `struct sctp_association` and does not introduce any new data structures, allocations, or data copied to user space. There is no risk of uninitialized memory reads or info-leaks exposed by these changes. Standard KASAN and other bug detectors are sufficient to catch any memory corruption or out-of-bounds accesses related to this code.",
"NeedsKMSAN": false
}Instruction: 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.
Prompt: For your convenience, here is the diff of the changes:
commit 186785661f91b6bd34fdd06aa413b2f147299e53
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Aug 24 09:07:19 2026 +0000
syz-cluster: applied patch under review
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index cccc662561aac..b21f23b736fd2 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -2057,7 +2057,7 @@ struct sctp_association {
force_delay:1;
__u8 strreset_enable;
- __u8 strreset_outstanding; /* request param count on the fly */
+ __u8 strreset_outstanding; /* request param bitmask on the fly */
__u32 strreset_outseq; /* Update after receiving response */
__u32 strreset_inseq; /* Update after receiving request */
diff --git a/net/sctp/stream.c b/net/sctp/stream.c
index 34ffe6c945a4b..9fee0da78845c 100644
--- a/net/sctp/stream.c
+++ b/net/sctp/stream.c
@@ -22,6 +22,15 @@
#include <net/sctp/sm.h>
#include <net/sctp/stream_sched.h>
+#define SCTP_STRRESET_MASK(type) \
+ BIT(ntohs(type) - ntohs(SCTP_PARAM_RESET_OUT_REQUEST))
+#define SCTP_STRRESET_TEST(asoc, type) \
+ ((asoc)->strreset_outstanding & SCTP_STRRESET_MASK(type))
+#define SCTP_STRRESET_SET(asoc, type) \
+ ((asoc)->strreset_outstanding |= SCTP_STRRESET_MASK(type))
+#define SCTP_STRRESET_CLEAR(asoc, type) \
+ ((asoc)->strreset_outstanding &= ~SCTP_STRRESET_MASK(type))
+
static void sctp_stream_shrink_out(struct sctp_stream *stream, __u16 outcnt)
{
struct sctp_association *asoc;
@@ -372,7 +381,10 @@ int sctp_send_reset_streams(struct sctp_association *asoc,
goto out;
}
- asoc->strreset_outstanding = out + in;
+ if (out)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);
+ if (in)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_IN_REQUEST);
out:
return retval;
@@ -417,7 +429,7 @@ int sctp_send_reset_assoc(struct sctp_association *asoc)
return retval;
}
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_TSN_REQUEST);
return 0;
}
@@ -474,7 +486,10 @@ int sctp_send_add_streams(struct sctp_association *asoc,
goto out;
}
- asoc->strreset_outstanding = !!out + !!in;
+ if (out)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);
+ if (in)
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);
out:
return retval;
@@ -482,7 +497,7 @@ int sctp_send_add_streams(struct sctp_association *asoc,
static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(
struct sctp_association *asoc, __be32 resp_seq,
- __be16 type)
+ __be16 type, bool match_seq)
{
struct sctp_chunk *chunk = asoc->strreset_chunk;
struct sctp_reconf_chunk *hdr;
@@ -499,7 +514,7 @@ static struct sctp_paramhdr *sctp_chunk_lookup_strreset_param(
*/
struct sctp_strreset_tsnreq *req = param.v;
- if ((!resp_seq || req->request_seq == resp_seq) &&
+ if ((!match_seq || req->request_seq == resp_seq) &&
(!type || type == req->param_hdr.type))
return param.v;
}
@@ -564,13 +579,14 @@ struct sctp_chunk *sctp_process_strreset_outreq(
if (asoc->strreset_chunk) {
if (!sctp_chunk_lookup_strreset_param(
asoc, outreq->response_seq,
- SCTP_PARAM_RESET_IN_REQUEST)) {
+ SCTP_PARAM_RESET_IN_REQUEST, true) ||
+ !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_IN_REQUEST)) {
/* same process with outstanding isn't 0 */
result = SCTP_STRRESET_ERR_IN_PROGRESS;
goto out;
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_IN_REQUEST);
asoc->strreset_outseq++;
if (!asoc->strreset_outstanding) {
@@ -669,7 +685,7 @@ struct sctp_chunk *sctp_process_strreset_inreq(
SCTP_SO(stream, i)->state = SCTP_STREAM_CLOSED;
asoc->strreset_chunk = chunk;
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_OUT_REQUEST);
sctp_chunk_hold(asoc->strreset_chunk);
result = SCTP_STRRESET_PERFORMED;
@@ -816,13 +832,14 @@ struct sctp_chunk *sctp_process_strreset_addstrm_out(
if (asoc->strreset_chunk) {
if (!sctp_chunk_lookup_strreset_param(
- asoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {
+ asoc, 0, SCTP_PARAM_RESET_ADD_IN_STREAMS, false) ||
+ !SCTP_STRRESET_TEST(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS)) {
/* same process with outstanding isn't 0 */
result = SCTP_STRRESET_ERR_IN_PROGRESS;
goto out;
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, SCTP_PARAM_RESET_ADD_IN_STREAMS);
asoc->strreset_outseq++;
if (!asoc->strreset_outstanding) {
@@ -899,7 +916,7 @@ struct sctp_chunk *sctp_process_strreset_addstrm_in(
goto out;
asoc->strreset_chunk = chunk;
- asoc->strreset_outstanding = 1;
+ SCTP_STRRESET_SET(asoc, SCTP_PARAM_RESET_ADD_OUT_STREAMS);
sctp_chunk_hold(asoc->strreset_chunk);
stream->outcnt = outcnt;
@@ -927,8 +944,9 @@ struct sctp_chunk *sctp_process_strreset_resp(
struct sctp_paramhdr *req;
__u32 result;
- req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0);
- if (!req)
+ req = sctp_chunk_lookup_strreset_param(asoc, resp->response_seq, 0,
+ true);
+ if (!req || !SCTP_STRRESET_TEST(asoc, req->type))
return NULL;
result = ntohl(resp->result);
@@ -1078,7 +1096,7 @@ struct sctp_chunk *sctp_process_strreset_resp(
nums, 0, GFP_ATOMIC);
}
- asoc->strreset_outstanding--;
+ SCTP_STRRESET_CLEAR(asoc, req->type);
asoc->strreset_outseq++;
/* remove everything for this reconf request */
|
| 13/3 | 2026/08/24 09:07 | llm | kmsan-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 4091 output: 126 thoughts: 516 Thoughts: **SCTP Stream Reset Bug Fix: A Bitmask Solution** Okay, so I've reviewed this patch focusing on SCTP stream reset. My initial assessment is that it's a solid, logic-focused improvement. The core change is the shift from a simple counter (`strreset_outstanding`) to a bitmask to track outstanding stream reset requests. Clever. They've introduced macros for bit manipulation, which makes the code cleaner and easier to understand: `SCTP_STRRESET_MASK`, `SCTP_STRRESET_TEST`, `SCTP_STRRESET_SET`, and `SCTP_STRRESET_CLEAR`. This is the right approach. I see that the patch touches a bunch of functions related to stream reset operations: `sctp_send_reset_streams`, `sctp_send_reset_assoc`, `sctp_send_add_streams`, the chunk lookup and processing functions... all the usual suspects. But the interesting part is the type of changes made. It's all about how `strreset_outstanding` is *used* and managed; no new data structures are introduced, no new allocations, nothing sent to user space that would raise red flags about security or potential info-leaks. My main concern, always, is memory safety. But after going through the code changes carefully, it's clear the patch is solely logic based. The `strreset_outstanding` variable, the focus of the change, is a simple `__u8` within the `struct sctp_association`. The patch *modifies* how it's *updated and checked*, but it doesn't introduce any new potential for memory corruption, out-of-bounds reads, or info leaks through uninitialized memory. There's no KMSAN-specific issue here. We don't need to enable KMSAN. Good; standard KASAN and the usual memory safety tools are going to be sufficient for catching anything that might be missed here. This is a logic bug fix, not a memory bug fix. Therefore, `NeedsKMSAN=false`. My reasoning is solid: replacing a counter with a bitmask is a straightforward optimization that shouldn't introduce any new memory safety concerns. |
| 14/3 | 2026/08/24 09:08 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch changes the tracking of outstanding SCTP stream reset requests from a simple counter to a bitmask. It modifies internal state tracking logic in `struct sctp_association` and does not introduce any new data structures, allocations, or data copied to user space. There is no risk of uninitialized memory reads or info-leaks exposed by these changes. Standard KASAN and other bug detectors are sufficient to catch any memory corruption or out-of-bounds accesses related to this code.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch changes the tracking of outstanding SCTP stream reset requests from a simple counter to a bitmask. It modifies internal state tracking logic in `struct sctp_association` and does not introduce any new data structures, allocations, or data copied to user space. There is no risk of uninitialized memory reads or info-leaks exposed by these changes. Standard KASAN and other bug detectors are sufficient to catch any memory corruption or out-of-bounds accesses related to this code.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|