AI Trajectory

null

{
  "EnableConfigs": [
    "VHOST_NET"
  ],
  "FocusSymbols": [
    "vhost_net_hdr_from_sock",
    "handle_rx"
  ],
  "Reasoning": "The patch introduces functional changes to vhost-net to support guest TSO and checksum offloads by populating virtio_net_hdr from the socket skb. This logic is reachable via vhost-net operations and network traffic.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 9d0b083fa5545e5028efc29425bcf77991383845\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Jul 13 01:30:24 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/vhost/net.c b/drivers/vhost/net.c\nindex 77b59f49bddb3d..d1e4a8325270e2 100644\n--- a/drivers/vhost/net.c\n+++ b/drivers/vhost/net.c\n@@ -73,6 +73,10 @@ static const int vhost_net_bits[] = {\n \tVHOST_FEATURES,\n \tVHOST_NET_F_VIRTIO_NET_HDR,\n \tVIRTIO_NET_F_MRG_RXBUF,\n+\tVIRTIO_NET_F_GUEST_CSUM,\n+\tVIRTIO_NET_F_GUEST_TSO4,\n+\tVIRTIO_NET_F_GUEST_TSO6,\n+\tVIRTIO_NET_F_GUEST_ECN,\n \tVIRTIO_F_ACCESS_PLATFORM,\n \tVIRTIO_F_RING_RESET,\n \tVIRTIO_F_IN_ORDER,\n@@ -644,7 +648,7 @@ static bool vhost_exceeds_maxpend(struct vhost_net *net)\n static size_t init_iov_iter(struct vhost_virtqueue *vq, struct iov_iter *iter,\n \t\t\t    size_t hdr_size, int out)\n {\n-\t/* Skip header. TODO: support TSO. */\n+\t/* Skip guest virtio_net_hdr; TX TSO handled in a follow-up. */\n \tsize_t len = iov_length(vq-\u003eiov, out);\n \n \tiov_iter_init(iter, ITER_SOURCE, vq-\u003eiov, out, len);\n@@ -1025,6 +1029,35 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)\n \treturn len;\n }\n \n+/*\n+ * When VHOST_NET_F_VIRTIO_NET_HDR is set, vhost supplies virtio_net_hdr.\n+ * Populate GSO/checksum metadata from the socket skb so guests that\n+ * negotiated GUEST_TSO*/GUEST_CSUM receive correct offload information.\n+ */\n+static int vhost_net_hdr_from_sock(struct vhost_virtqueue *vq, struct sock *sk,\n+\t\t\t\t   struct virtio_net_hdr *hdr)\n+{\n+\tstruct sk_buff *skb;\n+\tunsigned long flags;\n+\tint vlan_hlen = 0;\n+\tint ret;\n+\n+\tspin_lock_irqsave(\u0026sk-\u003esk_receive_queue.lock, flags);\n+\tskb = skb_peek(\u0026sk-\u003esk_receive_queue);\n+\tif (!skb) {\n+\t\tspin_unlock_irqrestore(\u0026sk-\u003esk_receive_queue.lock, flags);\n+\t\tmemset(hdr, 0, sizeof(*hdr));\n+\t\thdr-\u003egso_type = VIRTIO_NET_HDR_GSO_NONE;\n+\t\treturn 0;\n+\t}\n+\tif (skb_vlan_tag_present(skb))\n+\t\tvlan_hlen = VLAN_HLEN;\n+\tret = virtio_net_hdr_from_skb(skb, hdr, vhost_is_little_endian(vq),\n+\t\t\t\t      true, vlan_hlen);\n+\tspin_unlock_irqrestore(\u0026sk-\u003esk_receive_queue.lock, flags);\n+\treturn ret;\n+}\n+\n static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,\n \t\t\t\t      bool *busyloop_intr, unsigned int *count)\n {\n@@ -1239,10 +1272,18 @@ static void handle_rx(struct vhost_net *net)\n \t\t/* We don't need to be notified again. */\n \t\tiov_iter_init(\u0026msg.msg_iter, ITER_DEST, vq-\u003eiov, in, vhost_len);\n \t\tfixup = msg.msg_iter;\n-\t\tif (unlikely((vhost_hlen))) {\n-\t\t\t/* We will supply the header ourselves\n-\t\t\t * TODO: support TSO.\n+\t\tif (unlikely(vhost_hlen)) {\n+\t\t\t/*\n+\t\t\t * Build virtio_net_hdr from the socket skb before\n+\t\t\t * recvmsg consumes it. Skip for ptr_ring backends\n+\t\t\t * where the skb is not on sk_receive_queue.\n \t\t\t */\n+\t\t\tif (!nvq-\u003erx_ring \u0026\u0026\n+\t\t\t    vhost_net_hdr_from_sock(vq, sock-\u003esk, \u0026hdr)) {\n+\t\t\t\tvq_err(vq, \"Failed to build vnet_hdr from skb\\n\");\n+\t\t\t\tvhost_discard_vq_desc(vq, headcount, ndesc);\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tiov_iter_advance(\u0026msg.msg_iter, vhost_hlen);\n \t\t}\n \t\terr = sock-\u003eops-\u003erecvmsg(sock, \u0026msg,\n@@ -1270,7 +1311,6 @@ static void handle_rx(struct vhost_net *net)\n \t\t\t */\n \t\t\tiov_iter_advance(\u0026fixup, sizeof(hdr));\n \t\t}\n-\t\t/* TODO: Should check and handle checksum. */\n \n \t\tnum_buffers = cpu_to_vhost16(vq, headcount);\n \t\tif (likely(set_num_buffers) \u0026\u0026\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "VHOST_NET"
  ],
  "FocusSymbols": [
    "vhost_net_hdr_from_sock",
    "handle_rx"
  ],
  "Reasoning": "The patch introduces functional changes to vhost-net to support guest TSO and checksum offloads by populating virtio_net_hdr from the socket skb. This logic is reachable via vhost-net operations and network traffic.",
  "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 9d0b083fa5545e5028efc29425bcf77991383845
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Jul 13 01:30:24 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 77b59f49bddb3d..d1e4a8325270e2 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -73,6 +73,10 @@ static const int vhost_net_bits[] = {
 	VHOST_FEATURES,
 	VHOST_NET_F_VIRTIO_NET_HDR,
 	VIRTIO_NET_F_MRG_RXBUF,
+	VIRTIO_NET_F_GUEST_CSUM,
+	VIRTIO_NET_F_GUEST_TSO4,
+	VIRTIO_NET_F_GUEST_TSO6,
+	VIRTIO_NET_F_GUEST_ECN,
 	VIRTIO_F_ACCESS_PLATFORM,
 	VIRTIO_F_RING_RESET,
 	VIRTIO_F_IN_ORDER,
@@ -644,7 +648,7 @@ static bool vhost_exceeds_maxpend(struct vhost_net *net)
 static size_t init_iov_iter(struct vhost_virtqueue *vq, struct iov_iter *iter,
 			    size_t hdr_size, int out)
 {
-	/* Skip header. TODO: support TSO. */
+	/* Skip guest virtio_net_hdr; TX TSO handled in a follow-up. */
 	size_t len = iov_length(vq->iov, out);
 
 	iov_iter_init(iter, ITER_SOURCE, vq->iov, out, len);
@@ -1025,6 +1029,35 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
 	return len;
 }
 
+/*
+ * When VHOST_NET_F_VIRTIO_NET_HDR is set, vhost supplies virtio_net_hdr.
+ * Populate GSO/checksum metadata from the socket skb so guests that
+ * negotiated GUEST_TSO*/GUEST_CSUM receive correct offload information.
+ */
+static int vhost_net_hdr_from_sock(struct vhost_virtqueue *vq, struct sock *sk,
+				   struct virtio_net_hdr *hdr)
+{
+	struct sk_buff *skb;
+	unsigned long flags;
+	int vlan_hlen = 0;
+	int ret;
+
+	spin_lock_irqsave(&sk->sk_receive_queue.lock, flags);
+	skb = skb_peek(&sk->sk_receive_queue);
+	if (!skb) {
+		spin_unlock_irqrestore(&sk->sk_receive_queue.lock, flags);
+		memset(hdr, 0, sizeof(*hdr));
+		hdr->gso_type = VIRTIO_NET_HDR_GSO_NONE;
+		return 0;
+	}
+	if (skb_vlan_tag_present(skb))
+		vlan_hlen = VLAN_HLEN;
+	ret = virtio_net_hdr_from_skb(skb, hdr, vhost_is_little_endian(vq),
+				      true, vlan_hlen);
+	spin_unlock_irqrestore(&sk->sk_receive_queue.lock, flags);
+	return ret;
+}
+
 static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,
 				      bool *busyloop_intr, unsigned int *count)
 {
@@ -1239,10 +1272,18 @@ static void handle_rx(struct vhost_net *net)
 		/* We don't need to be notified again. */
 		iov_iter_init(&msg.msg_iter, ITER_DEST, vq->iov, in, vhost_len);
 		fixup = msg.msg_iter;
-		if (unlikely((vhost_hlen))) {
-			/* We will supply the header ourselves
-			 * TODO: support TSO.
+		if (unlikely(vhost_hlen)) {
+			/*
+			 * Build virtio_net_hdr from the socket skb before
+			 * recvmsg consumes it. Skip for ptr_ring backends
+			 * where the skb is not on sk_receive_queue.
 			 */
+			if (!nvq->rx_ring &&
+			    vhost_net_hdr_from_sock(vq, sock->sk, &hdr)) {
+				vq_err(vq, "Failed to build vnet_hdr from skb\n");
+				vhost_discard_vq_desc(vq, headcount, ndesc);
+				continue;
+			}
 			iov_iter_advance(&msg.msg_iter, vhost_hlen);
 		}
 		err = sock->ops->recvmsg(sock, &msg,
@@ -1270,7 +1311,6 @@ static void handle_rx(struct vhost_net *net)
 			 */
 			iov_iter_advance(&fixup, sizeof(hdr));
 		}
-		/* TODO: Should check and handle checksum. */
 
 		num_buffers = cpu_to_vhost16(vq, headcount);
 		if (likely(set_num_buffers) &&

gemini-3.1-pro-preview

null

null

							input: 2969
							output: 30
							thoughts: 272
						

**My Assessment of the vhost-net Patch**

Okay, so I'm looking at this patch for `drivers/vhost/net.c`. My initial read tells me it's adding some important new capabilities for the guest. Specifically, it's enabling guest-side checksum offload (`VIRTIO_NET_F_GUEST_CSUM`), and the various TSO offloads (TSO4, TSO6, and ECN) within the `vhost_net_bits` structure. That’s a good step forward.

The comment update in `init_iov_iter` is minor, but important for clarifying the code. The real meat of it is the addition of `vhost_net_hdr_from_sock`.  That function is key, as it's responsible for mapping the socket's `skb` (socket buffer) to the `virtio_net_hdr`. The subsequent modification to `handle_rx` to actually *use* that function to populate the header is the critical piece that ties it all together. This makes sense; it's the core of how vhost-net would handle the receive path with these new features.

Functionally, this means the guest now has support for these checksum and TSO offloads. This is a solid, functional change. The code is triggered by the standard vhost-net ioctls and, more importantly, *real* network traffic.

Thinking like a fuzzing expert, `vhost_net_hdr_from_sock` immediately jumps out as a prime target. Any subtle misinterpretation of the `skb` data, or edge cases in handling the header construction, could lead to vulnerabilities. I also need to flag `handle_rx` as a second top candidate for more testing.

Before I go further, I should verify the vhost-net configuration. I'll need to check `drivers/vhost/Kconfig` to confirm that `CONFIG_VHOST_NET` is indeed enabled. I don't want to waste time on a feature that isn't actually compiled in.

{
  "Expression": "config VHOST_NET",
  "PathPrefix": "drivers/vhost/"
}

{
  "Output": "drivers/vhost/Kconfig=32=if VHOST_MENU\ndrivers/vhost/Kconfig-33-\ndrivers/vhost/Kconfig:34:config VHOST_NET\ndrivers/vhost/Kconfig-35-\ttristate \"Host kernel accelerator for virtio net\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 3796
							output: 38
							thoughts: 34
						

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

**Investigating the `VHOST_NET` Configuration and Data Flow**

Alright, so the initial focus is on `VHOST_NET`. Right. That's the key. Let's see... I need to quickly refresh my understanding of where the rubber meets the road with that module. Specifically, let's drill down into the critical functions: `vhost_net_hdr_from_sock` and `handle_rx`. My instinct is that these are the lynchpins in understanding how the data actually gets from the socket into the virtualized environment. `vhost_net_hdr_from_sock` is likely where the packet header is crafted or extracted, and `handle_rx`... that's where the actual packet processing and delivery within the virtual machine happen. Knowing *exactly* how data is marshalled and handled between those two points is where the interesting stuff happens. I need to trace the data flow through those function calls and the surrounding context to understand how the packet gets handled. This is going to give me the information I need.

{
  "Expression": "vhost_net_hdr_from_sock",
  "PathPrefix": "drivers/vhost/net.c"
}

{
  "Output": "drivers/vhost/net.c=1011=static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)\n--\ndrivers/vhost/net.c-1036- */\ndrivers/vhost/net.c:1037:static int vhost_net_hdr_from_sock(struct vhost_virtqueue *vq, struct sock *sk,\ndrivers/vhost/net.c-1038-\t\t\t\t   struct virtio_net_hdr *hdr)\n--\ndrivers/vhost/net.c=1180=static void handle_rx(struct vhost_net *net)\n--\ndrivers/vhost/net.c-1281-\t\t\tif (!nvq-\u003erx_ring \u0026\u0026\ndrivers/vhost/net.c:1282:\t\t\t    vhost_net_hdr_from_sock(vq, sock-\u003esk, \u0026hdr)) {\ndrivers/vhost/net.c-1283-\t\t\t\tvq_err(vq, \"Failed to build vnet_hdr from skb\\n\");\n"
}

gemini-3.1-pro-preview

null

null

							input: 4380
							output: 103
							thoughts: 59
						

**My Assessment of the New vhost-net Patch**

Okay, so this patch introduces some functional modifications to `vhost-net`, specifically aiming to enable guest TSO (TCP Segmentation Offload) and checksum offloading. This is interesting, and it immediately screams potential fuzzing target. Anytime you're dealing with network offloads, especially in a virtualized context, you have to be extra vigilant about potential security vulnerabilities. Given the nature of these changes, I need to prioritize fuzzing this code.

I need to focus my fuzzing efforts on a couple of key symbols: `vhost_net_hdr_from_sock`, which likely handles the transition of data from the socket layer to the vhost-net layer, and `handle_rx`, which is undoubtedly responsible for processing incoming packets. These are the obvious entry points and potentially complex data transformation points. I’ll make sure the `VHOST_NET` configuration option is enabled during my fuzzing campaign, obviously. Let's get cracking.

{
  "EnableConfigs": [
    "VHOST_NET"
  ],
  "FocusSymbols": [
    "vhost_net_hdr_from_sock",
    "handle_rx"
  ],
  "Reasoning": "The patch introduces functional changes to vhost-net to support guest TSO and checksum offloads by populating virtio_net_hdr from the socket skb. This logic is reachable via vhost-net operations and network traffic.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "VHOST_NET"
  ],
  "FocusSymbols": [
    "vhost_net_hdr_from_sock",
    "handle_rx"
  ],
  "Reasoning": "The patch introduces functional changes to vhost-net to support guest TSO and checksum offloads by populating virtio_net_hdr from the socket skb. This logic is reachable via vhost-net operations and network traffic.",
  "WorthFuzzing": true
}