AI Trajectory

null

{
  "EnableConfigs": [
    "TLS"
  ],
  "FocusSymbols": [
    "tls_sw_splice_read"
  ],
  "Reasoning": "The patch modifies the `tls_sw_splice_read` function in the TLS subsystem to coalesce successive DATA records into the pipe, altering the behavior of the `splice` system call on TLS sockets. This is a functional change in reachable core kernel logic that should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 64b6d83d159780e574c51e7d996e7335d3b271e0\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Jul 12 15:08:58 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c\nindex d4afc90fd7966e..8bc0361e3bf426 100644\n--- a/net/tls/tls_sw.c\n+++ b/net/tls/tls_sw.c\n@@ -1986,8 +1986,11 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,\n {\n \tstruct tls_context *tls_ctx = tls_get_ctx(sock-\u003esk);\n \tstruct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);\n+\tstruct tls_prot_info *prot = \u0026tls_ctx-\u003eprot_info;\n \tstruct strp_msg *rxm = NULL;\n \tstruct sock *sk = sock-\u003esk;\n+\tsize_t flushed_at = 0;\n+\tbool released = true;\n \tstruct tls_msg *tlm;\n \tstruct sk_buff *skb;\n \tssize_t copied = 0;\n@@ -1998,47 +2001,81 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,\n \tif (err \u003c 0)\n \t\treturn err;\n \n-\tif (!skb_queue_empty(\u0026ctx-\u003erx_list)) {\n-\t\tskb = __skb_dequeue(\u0026ctx-\u003erx_list);\n-\t} else {\n-\t\tstruct tls_decrypt_arg darg;\n+\t/* Coalesce successive DATA records into the pipe, the way\n+\t * tls_sw_recvmsg() coalesces into the msg buffer, instead of\n+\t * returning one record per call. Only the first record may block.\n+\t */\n+\twhile (copied \u003c len) {\n+\t\tbool first = !copied;\n \n-\t\terr = tls_rx_rec_wait(sk, flags \u0026 SPLICE_F_NONBLOCK,\n-\t\t\t\t      true, false);\n-\t\tif (err \u003c= 0)\n-\t\t\tgoto splice_read_end;\n+\t\tif (!skb_queue_empty(\u0026ctx-\u003erx_list)) {\n+\t\t\tskb = __skb_dequeue(\u0026ctx-\u003erx_list);\n+\t\t} else {\n+\t\t\tstruct tls_decrypt_arg darg;\n \n-\t\tmemset(\u0026darg.inargs, 0, sizeof(darg.inargs));\n+\t\t\terr = tls_rx_rec_wait(sk,\n+\t\t\t\t\t      first ? (flags \u0026 SPLICE_F_NONBLOCK) : true,\n+\t\t\t\t\t      released, !first);\n+\t\t\tif (err \u003c= 0)\n+\t\t\t\tgoto splice_read_end;\n \n-\t\terr = tls_rx_one_record(sk, NULL, \u0026darg);\n-\t\tif (err \u003c 0)\n-\t\t\tgoto splice_read_end;\n+\t\t\tmemset(\u0026darg.inargs, 0, sizeof(darg.inargs));\n \n-\t\ttls_rx_rec_done(ctx);\n-\t\tskb = darg.skb;\n-\t}\n+\t\t\terr = tls_rx_one_record(sk, NULL, \u0026darg);\n+\t\t\tif (err \u003c 0)\n+\t\t\t\tgoto splice_read_end;\n \n-\trxm = strp_msg(skb);\n-\ttlm = tls_msg(skb);\n+\t\t\treleased = tls_read_flush_backlog(sk, prot,\n+\t\t\t\t\t\t\t  len - copied, 0,\n+\t\t\t\t\t\t\t  copied, \u0026flushed_at);\n+\t\t\ttls_rx_rec_done(ctx);\n+\t\t\tskb = darg.skb;\n+\t\t}\n \n-\t/* splice does not support reading control messages */\n-\tif (tlm-\u003econtrol != TLS_RECORD_TYPE_DATA) {\n-\t\terr = -EINVAL;\n-\t\tgoto splice_requeue;\n-\t}\n+\t\trxm = strp_msg(skb);\n+\t\ttlm = tls_msg(skb);\n \n-\tchunk = min_t(unsigned int, rxm-\u003efull_len, len);\n-\tcopied = skb_splice_bits(skb, sk, rxm-\u003eoffset, pipe, chunk, flags);\n-\tif (copied \u003c 0)\n-\t\tgoto splice_requeue;\n+\t\t/* splice does not support reading control messages\n+\t\t * mid batch the record is left on rx_list for the next call\n+\t\t */\n+\t\tif (tlm-\u003econtrol != TLS_RECORD_TYPE_DATA) {\n+\t\t\terr = -EINVAL;\n+\t\t\tgoto splice_requeue;\n+\t\t}\n \n-\tif (copied \u003c rxm-\u003efull_len) {\n-\t\trxm-\u003eoffset += copied;\n-\t\trxm-\u003efull_len -= copied;\n-\t\tgoto splice_requeue;\n-\t}\n+\t\t/* Records after the first must not block on pipe space,\n+\t\t * stop if this one does not already fit\n+\t\t */\n+\t\tif (!first) {\n+\t\t\tunsigned int need = DIV_ROUND_UP(rxm-\u003efull_len,\n+\t\t\t\t\t\t\t PAGE_SIZE);\n+\n+\t\t\tif (pipe_occupancy(pipe-\u003ehead, pipe-\u003etail) + need \u003e\n+\t\t\t    pipe-\u003emax_usage) {\n+\t\t\t\t__skb_queue_head(\u0026ctx-\u003erx_list, skb);\n+\t\t\t\tgoto splice_read_end;\n+\t\t\t}\n+\t\t}\n+\n+\t\tchunk = min_t(unsigned int, rxm-\u003efull_len, len - copied);\n+\t\tchunk = skb_splice_bits(skb, sk, rxm-\u003eoffset, pipe, chunk,\n+\t\t\t\t\tflags);\n+\t\tif (chunk \u003c 0) {\n+\t\t\terr = chunk;\n+\t\t\tgoto splice_requeue;\n+\t\t}\n \n-\tconsume_skb(skb);\n+\t\tcopied += chunk;\n+\n+\t\t/* pipe full, requeue the remainder */\n+\t\tif (chunk \u003c rxm-\u003efull_len) {\n+\t\t\trxm-\u003eoffset += chunk;\n+\t\t\trxm-\u003efull_len -= chunk;\n+\t\t\tgoto splice_requeue;\n+\t\t}\n+\n+\t\tconsume_skb(skb);\n+\t}\n \n splice_read_end:\n \ttls_rx_reader_unlock(sk, ctx);\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "TLS"
  ],
  "FocusSymbols": [
    "tls_sw_splice_read"
  ],
  "Reasoning": "The patch modifies the `tls_sw_splice_read` function in the TLS subsystem to coalesce successive DATA records into the pipe, altering the behavior of the `splice` system call on TLS sockets. This is a functional change in reachable core kernel logic 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).

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit 64b6d83d159780e574c51e7d996e7335d3b271e0
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Jul 12 15:08:58 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index d4afc90fd7966e..8bc0361e3bf426 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1986,8 +1986,11 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,
 {
 	struct tls_context *tls_ctx = tls_get_ctx(sock->sk);
 	struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+	struct tls_prot_info *prot = &tls_ctx->prot_info;
 	struct strp_msg *rxm = NULL;
 	struct sock *sk = sock->sk;
+	size_t flushed_at = 0;
+	bool released = true;
 	struct tls_msg *tlm;
 	struct sk_buff *skb;
 	ssize_t copied = 0;
@@ -1998,47 +2001,81 @@ ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,
 	if (err < 0)
 		return err;
 
-	if (!skb_queue_empty(&ctx->rx_list)) {
-		skb = __skb_dequeue(&ctx->rx_list);
-	} else {
-		struct tls_decrypt_arg darg;
+	/* Coalesce successive DATA records into the pipe, the way
+	 * tls_sw_recvmsg() coalesces into the msg buffer, instead of
+	 * returning one record per call. Only the first record may block.
+	 */
+	while (copied < len) {
+		bool first = !copied;
 
-		err = tls_rx_rec_wait(sk, flags & SPLICE_F_NONBLOCK,
-				      true, false);
-		if (err <= 0)
-			goto splice_read_end;
+		if (!skb_queue_empty(&ctx->rx_list)) {
+			skb = __skb_dequeue(&ctx->rx_list);
+		} else {
+			struct tls_decrypt_arg darg;
 
-		memset(&darg.inargs, 0, sizeof(darg.inargs));
+			err = tls_rx_rec_wait(sk,
+					      first ? (flags & SPLICE_F_NONBLOCK) : true,
+					      released, !first);
+			if (err <= 0)
+				goto splice_read_end;
 
-		err = tls_rx_one_record(sk, NULL, &darg);
-		if (err < 0)
-			goto splice_read_end;
+			memset(&darg.inargs, 0, sizeof(darg.inargs));
 
-		tls_rx_rec_done(ctx);
-		skb = darg.skb;
-	}
+			err = tls_rx_one_record(sk, NULL, &darg);
+			if (err < 0)
+				goto splice_read_end;
 
-	rxm = strp_msg(skb);
-	tlm = tls_msg(skb);
+			released = tls_read_flush_backlog(sk, prot,
+							  len - copied, 0,
+							  copied, &flushed_at);
+			tls_rx_rec_done(ctx);
+			skb = darg.skb;
+		}
 
-	/* splice does not support reading control messages */
-	if (tlm->control != TLS_RECORD_TYPE_DATA) {
-		err = -EINVAL;
-		goto splice_requeue;
-	}
+		rxm = strp_msg(skb);
+		tlm = tls_msg(skb);
 
-	chunk = min_t(unsigned int, rxm->full_len, len);
-	copied = skb_splice_bits(skb, sk, rxm->offset, pipe, chunk, flags);
-	if (copied < 0)
-		goto splice_requeue;
+		/* splice does not support reading control messages
+		 * mid batch the record is left on rx_list for the next call
+		 */
+		if (tlm->control != TLS_RECORD_TYPE_DATA) {
+			err = -EINVAL;
+			goto splice_requeue;
+		}
 
-	if (copied < rxm->full_len) {
-		rxm->offset += copied;
-		rxm->full_len -= copied;
-		goto splice_requeue;
-	}
+		/* Records after the first must not block on pipe space,
+		 * stop if this one does not already fit
+		 */
+		if (!first) {
+			unsigned int need = DIV_ROUND_UP(rxm->full_len,
+							 PAGE_SIZE);
+
+			if (pipe_occupancy(pipe->head, pipe->tail) + need >
+			    pipe->max_usage) {
+				__skb_queue_head(&ctx->rx_list, skb);
+				goto splice_read_end;
+			}
+		}
+
+		chunk = min_t(unsigned int, rxm->full_len, len - copied);
+		chunk = skb_splice_bits(skb, sk, rxm->offset, pipe, chunk,
+					flags);
+		if (chunk < 0) {
+			err = chunk;
+			goto splice_requeue;
+		}
 
-	consume_skb(skb);
+		copied += chunk;
+
+		/* pipe full, requeue the remainder */
+		if (chunk < rxm->full_len) {
+			rxm->offset += chunk;
+			rxm->full_len -= chunk;
+			goto splice_requeue;
+		}
+
+		consume_skb(skb);
+	}
 
 splice_read_end:
 	tls_rx_reader_unlock(sk, ctx);

gemini-3.1-pro-preview

null

null

							input: 3159
							output: 31
							thoughts: 129
						

**Analyzing the TLS Splicing Patch**

Okay, so I'm looking at this patch that tweaks `net/tls/tls_sw.c`, specifically the `tls_sw_splice_read` function. It seems they've updated the logic for how TLS data is spliced into a pipe. The key change is that it now coalesces consecutive DATA records, which is a significant departure from the previous one-record-per-call behavior. It's essentially mimicking the behavior of `tls_sw_recvmsg()` here. Interesting.

Now, before I dig too deep, I need to understand the relevant configurations.  I know `CONFIG_TLS` is the big one, but I need to make sure this new behavior doesn't clash with any other settings.  Time to get `grepper` out and hunt down the usages of `tls_sw_splice_read` within the codebase, and see what config dependencies exist. Let's see what we can find. This level of aggregation might introduce an issue with the underlying configurations, so I need to make sure I am aware of any potential issues.

{
  "Expression": "tls_sw_splice_read",
  "PathPrefix": "net/tls/"
}

{
  "Output": "net/tls/tls.h=165=bool tls_sw_sock_is_readable(struct sock *sk);\nnet/tls/tls.h:166:ssize_t tls_sw_splice_read(struct socket *sock, loff_t *ppos,\nnet/tls/tls.h-167-\t\t\t   struct pipe_inode_info *pipe,\n--\nnet/tls/tls_main.c=940=static void build_proto_ops(struct proto_ops ops[TLS_NUM_CONFIG][TLS_NUM_CONFIG],\n--\nnet/tls/tls_main.c-948-\tops[TLS_BASE][TLS_SW  ] = ops[TLS_BASE][TLS_BASE];\nnet/tls/tls_main.c:949:\tops[TLS_BASE][TLS_SW  ].splice_read\t= tls_sw_splice_read;\nnet/tls/tls_main.c-950-\tops[TLS_BASE][TLS_SW  ].poll\t\t= tls_sk_poll;\n--\nnet/tls/tls_main.c-953-\tops[TLS_SW  ][TLS_SW  ] = ops[TLS_SW  ][TLS_BASE];\nnet/tls/tls_main.c:954:\tops[TLS_SW  ][TLS_SW  ].splice_read\t= tls_sw_splice_read;\nnet/tls/tls_main.c-955-\tops[TLS_SW  ][TLS_SW  ].poll\t\t= tls_sk_poll;\n--\nnet/tls/tls_sw.c=1790=int tls_sw_recvmsg(struct sock *sk,\n--\nnet/tls/tls_sw.c-1982-\nnet/tls/tls_sw.c:1983:ssize_t tls_sw_splice_read(struct socket *sock,  loff_t *ppos,\nnet/tls/tls_sw.c-1984-\t\t\t   struct pipe_inode_info *pipe,\n"
}

gemini-3.1-pro-preview

null

null

							input: 4052
							output: 26
							thoughts: 45
						

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

**Analyzing a TLS Software Splice Read Patch**

Alright, so the focus is on a modification to `tls_sw_splice_read` within `net/tls/tls_sw.c`. This immediately tells me we're dealing with core functionality—likely the software implementation of the TLS splice read mechanism within the kernel. It's almost certainly functional code, meaning it's involved in the actual data transfer and processing, not just configuration. Given the location within the `net` directory, it will almost certainly be interacting with the network subsystem in some way.

Before diving deep into the code itself, I should probably check the `Kconfig` files under `net/tls/`. I need to understand any relevant configuration options or dependencies that might influence how this code behaves. Are we talking about a feature that can be enabled or disabled? Does it depend on specific hardware or other kernel modules? Understanding the build-time configuration context is crucial before I start assessing the impact of this change. Knowing what features are enabled, and under what circumstances, will determine what implications this patch may hold.

{
  "Expression": "config TLS",
  "PathPrefix": "net/tls/"
}

{
  "Output": "net/tls/Kconfig-4-#\nnet/tls/Kconfig:5:config TLS\nnet/tls/Kconfig-6-\ttristate \"Transport Layer Security support\"\n--\nnet/tls/Kconfig-18-\nnet/tls/Kconfig:19:config TLS_DEVICE\nnet/tls/Kconfig-20-\tbool \"Transport Layer Security HW offload\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4468
							output: 101
							thoughts: 229
						

**My Assessment of the TLS Patch**

Okay, so the core config option relevant to this patch is `CONFIG_TLS`. I need to zero in on the `tls_sw_splice_read` function. Based on the file path, `tls_sw.c`, and the context, `CONFIG_TLS_DEVICE` is for hardware offload, so we don't need to consider that, as this is the software implementation. `CONFIG_TLS` is the key.

Now, is `tls_sw_splice_read` actually reachable? Yes, and it's reached through the `splice` syscall when dealing with TLS sockets. The patch focuses specifically on making functional changes to `tls_sw_splice_read` to combine consecutive DATA records.

Just to be certain, I'll confirm – nope, `CONFIG_TLS` is still the only configuration item I need to keep in mind.

My focal point is definitively `tls_sw_splice_read`.

Ultimately, the patch directly modifies the `tls_sw_splice_read` function within the TLS subsystem, impacting how the `splice` system call functions on TLS sockets. By coalescing successive DATA records into the pipe, this introduces a functional alteration within reachable kernel logic. Given this functional change within core kernel code, I'm confident that this area demands fuzzing. I will now set the appropriate results.

{
  "EnableConfigs": [
    "TLS"
  ],
  "FocusSymbols": [
    "tls_sw_splice_read"
  ],
  "Reasoning": "The patch modifies the `tls_sw_splice_read` function in the TLS subsystem to coalesce successive DATA records into the pipe, altering the behavior of the `splice` system call on TLS sockets. This is a functional change in reachable core kernel logic that should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "TLS"
  ],
  "FocusSymbols": [
    "tls_sw_splice_read"
  ],
  "Reasoning": "The patch modifies the `tls_sw_splice_read` function in the TLS subsystem to coalesce successive DATA records into the pipe, altering the behavior of the `splice` system call on TLS sockets. This is a functional change in reachable core kernel logic that should be fuzzed.",
  "WorthFuzzing": true
}