AI Trajectory

null

{
  "EnableConfigs": [
    "VSOCKETS",
    "VSOCKETS_LOOPBACK",
    "VIRTIO_VSOCKETS"
  ],
  "FocusSymbols": [
    "vsock_connect"
  ],
  "KMSANReasoning": "The patch modifies state machine handling in vsock_connect() by treating TCP_CLOSING similarly to TCP_ESTABLISHED when checking sk-\u003esk_state upon waking from connection wait and error handling. This change affects socket control flow and state transitions only. It does not introduce any new allocations, modify buffer copying or sizing, touch uninitialized memory, or expose kernel structures/padding to userspace. Therefore, there are no uninitialized memory read or info-leak risks that would necessitate a dedicated KMSAN fuzzing session.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies vsock_connect() in net/vmw_vsock/af_vsock.c, changing the state validation logic during connection establishment and error handling by accommodating the TCP_CLOSING socket state. This affects reachable AF_VSOCK socket lifecycle transitions and warrants fuzzing.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 517ed47629540e82778f080a986641e7724e6161\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Sep 9 22:33:21 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c\nindex f840498b58afb..eec5dd6daebb1 100644\n--- a/net/vmw_vsock/af_vsock.c\n+++ b/net/vmw_vsock/af_vsock.c\n@@ -1834,23 +1834,20 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,\n \t\ttimeout = schedule_timeout(timeout);\n \t\tlock_sock(sk);\n \n-\t\t/* Connection established. Whatever happens to socket once we\n-\t\t * release it, that's not connect()'s concern. No need to go\n+\t\t/* Connection was established. Whatever happens to socket once\n+\t\t * we release it, that's not connect()'s concern. No need to go\n \t\t * into signal and timeout handling. Call it a day.\n \t\t *\n \t\t * Note that allowing to \"reset\" an already established socket\n \t\t * here is racy and insecure.\n \t\t */\n-\t\tif (sk-\u003esk_state == TCP_ESTABLISHED)\n+\t\tif (sk-\u003esk_state == TCP_ESTABLISHED ||\n+\t\t    sk-\u003esk_state == TCP_CLOSING)\n \t\t\tbreak;\n \n \t\t/* If connection was _not_ established and a signal/timeout came\n \t\t * to be, we want the socket's state reset. User space may want\n \t\t * to retry.\n-\t\t *\n-\t\t * sk_state != TCP_ESTABLISHED implies that socket is not on\n-\t\t * vsock_connected_table. We keep the binding and the transport\n-\t\t * assigned.\n \t\t */\n \t\tif (signal_pending(current) || timeout == 0) {\n \t\t\terr = timeout == 0 ? -ETIMEDOUT : sock_intr_errno(timeout);\n@@ -1875,7 +1872,8 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,\n \t}\n \n \terr = sock_error(sk);\n-\tif (err) {\n+\tif (err \u0026\u0026\n+\t    sk-\u003esk_state != TCP_ESTABLISHED \u0026\u0026 sk-\u003esk_state != TCP_CLOSING) {\n \t\tsk-\u003esk_state = TCP_CLOSE;\n \t\tsock-\u003estate = SS_UNCONNECTED;\n \t}\n"
}

core

null

{
  "EnableConfigs": [
    "VSOCKETS",
    "VSOCKETS_LOOPBACK",
    "VIRTIO_VSOCKETS"
  ],
  "FocusSymbols": [
    "vsock_connect"
  ],
  "Reasoning": "The patch modifies vsock_connect() in net/vmw_vsock/af_vsock.c, changing the state validation logic during connection establishment and error handling by accommodating the TCP_CLOSING socket state. This affects reachable AF_VSOCK socket lifecycle transitions and warrants fuzzing.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.

================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.

- REACHABILITY IS THE PRIMARY GATE:
  Fuzzing can only discover bugs in code that can actually execute in standard virtualized
  environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
  If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
  regardless of whether it adds assertions or complex logic.

- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
  Patch authors routinely label changes as "cleanups", "refactorings", or state
  "No functional change intended". Do NOT take these claims at face value.
  Code refactorings that rearrange logic, introduce helper functions, or alter state management
  in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
  If reachable executable code is modified or refactored, it MUST be fuzzed.

- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
  When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
  BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
  Even if the author believes the invariant always holds, fuzzing is essential to verify whether
  an unusual sequence of operations can violate it.

================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:

- Non-kernel and non-executable changes:
  * Modifications to Documentation/, comments, or spelling fixes.
  * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
    that do not affect the compiled kernel image (vmlinux) or kernel modules.
  * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
    that do not alter control flow or data structures.
  * Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
  * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
    ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
  * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
    physical PCI hot-unplug or manual sysfs driver unbinding.
  * Code paths exclusive to architectures other than the target architecture.

================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
  * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
    BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
  * Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
  * Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
  * Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).

================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:

- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
  Do NOT list generic, ubiquitous functions called by almost every program in the corpus
  (including, but not limited to: general memory allocators and deallocators, page fault
  and trap handlers, or core synchronization primitives; this is not an exhaustive list).
  Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
  which severely dilutes fuzzing effort away from the actual changes.

- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
  List functions that specifically implement the logic being added or altered, or direct API entrypoints
  for the subsystem feature under review.

- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
  Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
  distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
  If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
  functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).

================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any '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.

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 517ed47629540e82778f080a986641e7724e6161
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Sep 9 22:33:21 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index f840498b58afb..eec5dd6daebb1 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1834,23 +1834,20 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
 		timeout = schedule_timeout(timeout);
 		lock_sock(sk);
 
-		/* Connection established. Whatever happens to socket once we
-		 * release it, that's not connect()'s concern. No need to go
+		/* Connection was established. Whatever happens to socket once
+		 * we release it, that's not connect()'s concern. No need to go
 		 * into signal and timeout handling. Call it a day.
 		 *
 		 * Note that allowing to "reset" an already established socket
 		 * here is racy and insecure.
 		 */
-		if (sk->sk_state == TCP_ESTABLISHED)
+		if (sk->sk_state == TCP_ESTABLISHED ||
+		    sk->sk_state == TCP_CLOSING)
 			break;
 
 		/* If connection was _not_ established and a signal/timeout came
 		 * to be, we want the socket's state reset. User space may want
 		 * to retry.
-		 *
-		 * sk_state != TCP_ESTABLISHED implies that socket is not on
-		 * vsock_connected_table. We keep the binding and the transport
-		 * assigned.
 		 */
 		if (signal_pending(current) || timeout == 0) {
 			err = timeout == 0 ? -ETIMEDOUT : sock_intr_errno(timeout);
@@ -1875,7 +1872,8 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
 	}
 
 	err = sock_error(sk);
-	if (err) {
+	if (err &&
+	    sk->sk_state != TCP_ESTABLISHED && sk->sk_state != TCP_CLOSING) {
 		sk->sk_state = TCP_CLOSE;
 		sock->state = SS_UNCONNECTED;
 	}

gemini-3.7-flash

null

null

							input: 3258
							output: 43
							thoughts: 92
						

Okay, here's my analysis of the provided text, rendered as a first-person summary, keeping in mind my expertise:

**Diving into the vsock_connect Patch**

Alright, let's dissect this patch. My first instinct is to zero in on the context – specifically the `net/vmw_vsock/af_vsock.c` file within the `vsock_connect` function. I'm already formulating a plan.

I need to understand *why* this change was made, so I'll quickly need to examine the surrounding code. My preferred method here is likely going to be leveraging my tools. I'll reach for either `read-file` to get a quick visual of the file around line 1834, or, if I'm feeling lazy, I'll go with `grepper`, to quickly find where `vsock_connect` exists in relation to line 1834. Of course, `git grep` is always an option. I just need to get a clear picture of the surrounding lines, any relevant comments, and any previous commit messages that relate to that specific area. This context is crucial to forming an informed judgment on the patch's merit.

{
  "File": "net/vmw_vsock/af_vsock.c",
  "FirstLine": 1800,
  "LineCount": 90
}

{
  "Contents": "1800:\t\t/* The receive path will handle all communication until we are able to\n1801:\t\t * enter the connected state.  Here we wait for the connection to be\n1802:\t\t * completed or a notification of an error.\n1803:\t\t */\n1804:\t\ttimeout = vsk-\u003econnect_timeout;\n1805:\t\tprepare_to_wait(sk_sleep(sk), \u0026wait, TASK_INTERRUPTIBLE);\n1806:\t\n1807:\t\t/* If the socket is already closing or it is in an error state, there\n1808:\t\t * is no point in waiting.\n1809:\t\t */\n1810:\t\twhile (sk-\u003esk_state != TCP_ESTABLISHED \u0026\u0026\n1811:\t\t       sk-\u003esk_state != TCP_CLOSING \u0026\u0026 sk-\u003esk_err == 0) {\n1812:\t\t\tif (flags \u0026 O_NONBLOCK) {\n1813:\t\t\t\t/* If we're not going to block, we schedule a timeout\n1814:\t\t\t\t * function to generate a timeout on the connection\n1815:\t\t\t\t * attempt, in case the peer doesn't respond in a\n1816:\t\t\t\t * timely manner. We hold on to the socket until the\n1817:\t\t\t\t * timeout fires.\n1818:\t\t\t\t */\n1819:\t\t\t\tsock_hold(sk);\n1820:\t\n1821:\t\t\t\t/* If the timeout function is already scheduled,\n1822:\t\t\t\t * reschedule it, then ungrab the socket refcount to\n1823:\t\t\t\t * keep it balanced.\n1824:\t\t\t\t */\n1825:\t\t\t\tif (mod_delayed_work(system_percpu_wq, \u0026vsk-\u003econnect_work,\n1826:\t\t\t\t\t\t     timeout))\n1827:\t\t\t\t\tsock_put(sk);\n1828:\t\n1829:\t\t\t\t/* Skip ahead to preserve error code set above. */\n1830:\t\t\t\tgoto out_wait;\n1831:\t\t\t}\n1832:\t\n1833:\t\t\trelease_sock(sk);\n1834:\t\t\ttimeout = schedule_timeout(timeout);\n1835:\t\t\tlock_sock(sk);\n1836:\t\n1837:\t\t\t/* Connection was established. Whatever happens to socket once\n1838:\t\t\t * we release it, that's not connect()'s concern. No need to go\n1839:\t\t\t * into signal and timeout handling. Call it a day.\n1840:\t\t\t *\n1841:\t\t\t * Note that allowing to \"reset\" an already established socket\n1842:\t\t\t * here is racy and insecure.\n1843:\t\t\t */\n1844:\t\t\tif (sk-\u003esk_state == TCP_ESTABLISHED ||\n1845:\t\t\t    sk-\u003esk_state == TCP_CLOSING)\n1846:\t\t\t\tbreak;\n1847:\t\n1848:\t\t\t/* If connection was _not_ established and a signal/timeout came\n1849:\t\t\t * to be, we want the socket's state reset. User space may want\n1850:\t\t\t * to retry.\n1851:\t\t\t */\n1852:\t\t\tif (signal_pending(current) || timeout == 0) {\n1853:\t\t\t\terr = timeout == 0 ? -ETIMEDOUT : sock_intr_errno(timeout);\n1854:\t\n1855:\t\t\t\t/* Listener might have already responded with\n1856:\t\t\t\t * VIRTIO_VSOCK_OP_RESPONSE. Its handling expects our\n1857:\t\t\t\t * sk_state == TCP_SYN_SENT, which hereby we break.\n1858:\t\t\t\t * In such case VIRTIO_VSOCK_OP_RST will follow.\n1859:\t\t\t\t */\n1860:\t\t\t\tsk-\u003esk_state = TCP_CLOSE;\n1861:\t\t\t\tsock-\u003estate = SS_UNCONNECTED;\n1862:\t\n1863:\t\t\t\t/* Try to cancel VIRTIO_VSOCK_OP_REQUEST skb sent out by\n1864:\t\t\t\t * transport-\u003econnect().\n1865:\t\t\t\t */\n1866:\t\t\t\tvsock_transport_cancel_pkt(vsk);\n1867:\t\n1868:\t\t\t\tgoto out_wait;\n1869:\t\t\t}\n1870:\t\n1871:\t\t\tprepare_to_wait(sk_sleep(sk), \u0026wait, TASK_INTERRUPTIBLE);\n1872:\t\t}\n1873:\t\n1874:\t\terr = sock_error(sk);\n1875:\t\tif (err \u0026\u0026\n1876:\t\t    sk-\u003esk_state != TCP_ESTABLISHED \u0026\u0026 sk-\u003esk_state != TCP_CLOSING) {\n1877:\t\t\tsk-\u003esk_state = TCP_CLOSE;\n1878:\t\t\tsock-\u003estate = SS_UNCONNECTED;\n1879:\t\t}\n1880:\t\n1881:\tout_wait:\n1882:\t\tfinish_wait(sk_sleep(sk), \u0026wait);\n1883:\tout:\n1884:\t\trelease_sock(sk);\n1885:\t\treturn err;\n1886:\t}\n1887:\t\n1888:\tstatic int vsock_accept(struct socket *sock, struct socket *newsock,\n1889:\t\t\t\tstruct proto_accept_arg *arg)\n"
}

gemini-3.7-flash

null

null

							input: 5003
							output: 30
							thoughts: 87
						

**VSOCK Exploration**

Okay, let me get this straight. I need to dive into `vsock_connect`, and based on my understanding of the landscape, that function lives within `net/vmw_vsock/af_vsock.c`. Right, that makes sense. We're dealing with VSOCK, the AF_VSOCK socket protocol family, something I'm very familiar with. It's practically ubiquitous in virtualized environments – think vsock loopback, virtio-vsock, and even vmci, it all leverages that framework. I can't believe I didn't immediately consider checking Kconfig for information on `af_vsock.c`. Alright, let's start there. I'll get the information I need from the configuration file.

{
  "Expression": "VSOCK",
  "PathPrefix": "net/vmw_vsock/"
}

{
  "Output": "\nFull output is too long, showing 500 out of 1009 lines.\nUse more precise expression if possible.\n\nnet/vmw_vsock/Kconfig-5-\nnet/vmw_vsock/Kconfig:6:config VSOCKETS\nnet/vmw_vsock/Kconfig-7-\ttristate \"Virtual Socket protocol\"\n--\nnet/vmw_vsock/Kconfig-18-\nnet/vmw_vsock/Kconfig:19:config VSOCKETS_DIAG\nnet/vmw_vsock/Kconfig-20-\ttristate \"Virtual Sockets monitoring interface\"\nnet/vmw_vsock/Kconfig:21:\tdepends on VSOCKETS\nnet/vmw_vsock/Kconfig-22-\tdefault y\nnet/vmw_vsock/Kconfig-23-\thelp\nnet/vmw_vsock/Kconfig:24:\t  Support for PF_VSOCK sockets monitoring interface used by the ss tool.\nnet/vmw_vsock/Kconfig-25-\t  If unsure, say Y.\n--\nnet/vmw_vsock/Kconfig-28-\nnet/vmw_vsock/Kconfig:29:config VSOCKETS_LOOPBACK\nnet/vmw_vsock/Kconfig-30-\ttristate \"Virtual Sockets loopback transport\"\nnet/vmw_vsock/Kconfig:31:\tdepends on VSOCKETS\nnet/vmw_vsock/Kconfig-32-\tdefault y\nnet/vmw_vsock/Kconfig:33:\tselect VIRTIO_VSOCKETS_COMMON\nnet/vmw_vsock/Kconfig-34-\thelp\n--\nnet/vmw_vsock/Kconfig-40-\nnet/vmw_vsock/Kconfig:41:config VMWARE_VMCI_VSOCKETS\nnet/vmw_vsock/Kconfig-42-\ttristate \"VMware VMCI transport for Virtual Sockets\"\nnet/vmw_vsock/Kconfig:43:\tdepends on VSOCKETS \u0026\u0026 VMWARE_VMCI\nnet/vmw_vsock/Kconfig-44-\thelp\n--\nnet/vmw_vsock/Kconfig-52-\nnet/vmw_vsock/Kconfig:53:config VIRTIO_VSOCKETS\nnet/vmw_vsock/Kconfig-54-\ttristate \"virtio transport for Virtual Sockets\"\nnet/vmw_vsock/Kconfig:55:\tdepends on VSOCKETS \u0026\u0026 VIRTIO\nnet/vmw_vsock/Kconfig:56:\tselect VIRTIO_VSOCKETS_COMMON\nnet/vmw_vsock/Kconfig-57-\thelp\n--\nnet/vmw_vsock/Kconfig-65-\nnet/vmw_vsock/Kconfig:66:config VIRTIO_VSOCKETS_COMMON\nnet/vmw_vsock/Kconfig-67-\ttristate\n--\nnet/vmw_vsock/Kconfig-72-\nnet/vmw_vsock/Kconfig:73:config HYPERV_VSOCKETS\nnet/vmw_vsock/Kconfig-74-\ttristate \"Hyper-V transport for Virtual Sockets\"\nnet/vmw_vsock/Kconfig:75:\tdepends on VSOCKETS \u0026\u0026 HYPERV_VMBUS\nnet/vmw_vsock/Kconfig-76-\thelp\n--\nnet/vmw_vsock/Makefile-1-# SPDX-License-Identifier: GPL-2.0\nnet/vmw_vsock/Makefile:2:obj-$(CONFIG_VSOCKETS) += vsock.o\nnet/vmw_vsock/Makefile:3:obj-$(CONFIG_VSOCKETS_DIAG) += vsock_diag.o\nnet/vmw_vsock/Makefile:4:obj-$(CONFIG_VMWARE_VMCI_VSOCKETS) += vmw_vsock_vmci_transport.o\nnet/vmw_vsock/Makefile:5:obj-$(CONFIG_VIRTIO_VSOCKETS) += vmw_vsock_virtio_transport.o\nnet/vmw_vsock/Makefile:6:obj-$(CONFIG_VIRTIO_VSOCKETS_COMMON) += vmw_vsock_virtio_transport_common.o\nnet/vmw_vsock/Makefile:7:obj-$(CONFIG_HYPERV_VSOCKETS) += hv_sock.o\nnet/vmw_vsock/Makefile:8:obj-$(CONFIG_VSOCKETS_LOOPBACK) += vsock_loopback.o\nnet/vmw_vsock/Makefile-9-\n--\nnet/vmw_vsock/af_vsock.c-111- *        global namespace will not be able to allocate the same CID.\nnet/vmw_vsock/af_vsock.c:112: *      - global mode AF_VSOCK sockets can reach any VM or socket in any global\nnet/vmw_vsock/af_vsock.c-113- *        namespace, they are not contained to only their own namespace.\nnet/vmw_vsock/af_vsock.c:114: *      - AF_VSOCK sockets in a global mode namespace cannot reach VMs or\nnet/vmw_vsock/af_vsock.c-115- *        sockets in any local mode namespace.\n--\nnet/vmw_vsock/af_vsock.c-123- *       allocation in any other namespace, but not in the same namespace.\nnet/vmw_vsock/af_vsock.c:124: *     - AF_VSOCK sockets in a local mode namespace can connect only to VMs or\nnet/vmw_vsock/af_vsock.c-125- *       other sockets within their own namespace.\n--\nnet/vmw_vsock/af_vsock.c-167-\nnet/vmw_vsock/af_vsock.c:168:#define VSOCK_NET_MODE_STR_GLOBAL \"global\"\nnet/vmw_vsock/af_vsock.c:169:#define VSOCK_NET_MODE_STR_LOCAL \"local\"\nnet/vmw_vsock/af_vsock.c-170-\n--\nnet/vmw_vsock/af_vsock.c-173- */\nnet/vmw_vsock/af_vsock.c:174:#define VSOCK_NET_MODE_STR_MAX 8\nnet/vmw_vsock/af_vsock.c-175-\n--\nnet/vmw_vsock/af_vsock.c=182=struct proto vsock_proto = {\nnet/vmw_vsock/af_vsock.c:183:\t.name = \"AF_VSOCK\",\nnet/vmw_vsock/af_vsock.c-184-\t.owner = THIS_MODULE,\n--\nnet/vmw_vsock/af_vsock.c-194- */\nnet/vmw_vsock/af_vsock.c:195:#define VSOCK_DEFAULT_CONNECT_TIMEOUT (2 * HZ)\nnet/vmw_vsock/af_vsock.c-196-\nnet/vmw_vsock/af_vsock.c:197:#define VSOCK_DEFAULT_BUFFER_SIZE     (1024 * 256)\nnet/vmw_vsock/af_vsock.c:198:#define VSOCK_DEFAULT_BUFFER_MAX_SIZE (1024 * 256)\nnet/vmw_vsock/af_vsock.c:199:#define VSOCK_DEFAULT_BUFFER_MIN_SIZE 128\nnet/vmw_vsock/af_vsock.c-200-\n--\nnet/vmw_vsock/af_vsock.c=209=static DEFINE_MUTEX(vsock_register_mutex);\n--\nnet/vmw_vsock/af_vsock.c-221- * Specifically, we initialize the vsock_bind_table array to a size of\nnet/vmw_vsock/af_vsock.c:222: * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through\nnet/vmw_vsock/af_vsock.c:223: * vsock_bind_table[VSOCK_HASH_SIZE - 1] are for bound sockets and\nnet/vmw_vsock/af_vsock.c:224: * vsock_bind_table[VSOCK_HASH_SIZE] is for unbound sockets.  The hash function\nnet/vmw_vsock/af_vsock.c:225: * mods with VSOCK_HASH_SIZE to ensure this.\nnet/vmw_vsock/af_vsock.c-226- */\n--\nnet/vmw_vsock/af_vsock.c-228-\nnet/vmw_vsock/af_vsock.c:229:#define VSOCK_HASH(addr)        ((addr)-\u003esvm_port % VSOCK_HASH_SIZE)\nnet/vmw_vsock/af_vsock.c:230:#define vsock_bound_sockets(addr) (\u0026vsock_bind_table[VSOCK_HASH(addr)])\nnet/vmw_vsock/af_vsock.c:231:#define vsock_unbound_sockets     (\u0026vsock_bind_table[VSOCK_HASH_SIZE])\nnet/vmw_vsock/af_vsock.c-232-\nnet/vmw_vsock/af_vsock.c-233-/* XXX This can probably be implemented in a better way. */\nnet/vmw_vsock/af_vsock.c:234:#define VSOCK_CONN_HASH(src, dst)\t\t\t\t\\\nnet/vmw_vsock/af_vsock.c:235:\t(((src)-\u003esvm_cid ^ (dst)-\u003esvm_port) % VSOCK_HASH_SIZE)\nnet/vmw_vsock/af_vsock.c-236-#define vsock_connected_sockets(src, dst)\t\t\\\nnet/vmw_vsock/af_vsock.c:237:\t(\u0026vsock_connected_table[VSOCK_CONN_HASH(src, dst)])\nnet/vmw_vsock/af_vsock.c-238-#define vsock_connected_sockets_vsk(vsk)\t\t\t\t\\\n--\nnet/vmw_vsock/af_vsock.c-240-\nnet/vmw_vsock/af_vsock.c:241:struct list_head vsock_bind_table[VSOCK_HASH_SIZE + 1];\nnet/vmw_vsock/af_vsock.c-242-EXPORT_SYMBOL_GPL(vsock_bind_table);\nnet/vmw_vsock/af_vsock.c:243:struct list_head vsock_connected_table[VSOCK_HASH_SIZE];\nnet/vmw_vsock/af_vsock.c-244-EXPORT_SYMBOL_GPL(vsock_connected_table);\n--\nnet/vmw_vsock/af_vsock.c=936=static struct sock *__vsock_create(struct net *net,\n--\nnet/vmw_vsock/af_vsock.c-946-\nnet/vmw_vsock/af_vsock.c:947:\tsk = sk_alloc(net, AF_VSOCK, priority, \u0026vsock_proto, kern);\nnet/vmw_vsock/af_vsock.c-948-\tif (!sk)\n--\nnet/vmw_vsock/af_vsock.c-990-\t\tvsk-\u003eowner = get_current_cred();\nnet/vmw_vsock/af_vsock.c:991:\t\tvsk-\u003econnect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT;\nnet/vmw_vsock/af_vsock.c:992:\t\tvsk-\u003ebuffer_size = VSOCK_DEFAULT_BUFFER_SIZE;\nnet/vmw_vsock/af_vsock.c:993:\t\tvsk-\u003ebuffer_min_size = VSOCK_DEFAULT_BUFFER_MIN_SIZE;\nnet/vmw_vsock/af_vsock.c:994:\t\tvsk-\u003ebuffer_max_size = VSOCK_DEFAULT_BUFFER_MAX_SIZE;\nnet/vmw_vsock/af_vsock.c-995-\t}\n--\nnet/vmw_vsock/af_vsock.c=1653=static const struct proto_ops vsock_dgram_ops = {\nnet/vmw_vsock/af_vsock.c:1654:\t.family = PF_VSOCK,\nnet/vmw_vsock/af_vsock.c-1655-\t.owner = THIS_MODULE,\n--\nnet/vmw_vsock/af_vsock.c=1704=static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,\n--\nnet/vmw_vsock/af_vsock.c-1855-\t\t\t/* Listener might have already responded with\nnet/vmw_vsock/af_vsock.c:1856:\t\t\t * VIRTIO_VSOCK_OP_RESPONSE. Its handling expects our\nnet/vmw_vsock/af_vsock.c-1857-\t\t\t * sk_state == TCP_SYN_SENT, which hereby we break.\nnet/vmw_vsock/af_vsock.c:1858:\t\t\t * In such case VIRTIO_VSOCK_OP_RST will follow.\nnet/vmw_vsock/af_vsock.c-1859-\t\t\t */\n--\nnet/vmw_vsock/af_vsock.c-1862-\nnet/vmw_vsock/af_vsock.c:1863:\t\t\t/* Try to cancel VIRTIO_VSOCK_OP_REQUEST skb sent out by\nnet/vmw_vsock/af_vsock.c-1864-\t\t\t * transport-\u003econnect().\n--\nnet/vmw_vsock/af_vsock.c=2013=static int vsock_connectible_setsockopt(struct socket *sock,\n--\nnet/vmw_vsock/af_vsock.c-2024-\nnet/vmw_vsock/af_vsock.c:2025:\tif (level != AF_VSOCK \u0026\u0026 level != SOL_SOCKET)\nnet/vmw_vsock/af_vsock.c-2026-\t\treturn -ENOPROTOOPT;\n--\nnet/vmw_vsock/af_vsock.c-2106-\t\t\t\tvsk-\u003econnect_timeout =\nnet/vmw_vsock/af_vsock.c:2107:\t\t\t\t    VSOCK_DEFAULT_CONNECT_TIMEOUT;\nnet/vmw_vsock/af_vsock.c-2108-\n--\nnet/vmw_vsock/af_vsock.c=2127=static int vsock_connectible_getsockopt(struct socket *sock,\n--\nnet/vmw_vsock/af_vsock.c-2143-\nnet/vmw_vsock/af_vsock.c:2144:\tif (level != AF_VSOCK)\nnet/vmw_vsock/af_vsock.c-2145-\t\treturn -ENOPROTOOPT;\n--\nnet/vmw_vsock/af_vsock.c=2545=__vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,\n--\nnet/vmw_vsock/af_vsock.c-2555-\tif (unlikely(flags \u0026 MSG_ERRQUEUE))\nnet/vmw_vsock/af_vsock.c:2556:\t\treturn sock_recv_errqueue(sk, msg, len, SOL_VSOCK, VSOCK_RECVERR);\nnet/vmw_vsock/af_vsock.c-2557-\n--\nnet/vmw_vsock/af_vsock.c=2652=static const struct proto_ops vsock_stream_ops = {\nnet/vmw_vsock/af_vsock.c:2653:\t.family = PF_VSOCK,\nnet/vmw_vsock/af_vsock.c-2654-\t.owner = THIS_MODULE,\n--\nnet/vmw_vsock/af_vsock.c=2674=static const struct proto_ops vsock_seqpacket_ops = {\nnet/vmw_vsock/af_vsock.c:2675:\t.family = PF_VSOCK,\nnet/vmw_vsock/af_vsock.c-2676-\t.owner = THIS_MODULE,\n--\nnet/vmw_vsock/af_vsock.c=2695=static int vsock_create(struct net *net, struct socket *sock,\n--\nnet/vmw_vsock/af_vsock.c-2704-\nnet/vmw_vsock/af_vsock.c:2705:\tif (protocol \u0026\u0026 protocol != PF_VSOCK)\nnet/vmw_vsock/af_vsock.c-2706-\t\treturn -EPROTONOSUPPORT;\n--\nnet/vmw_vsock/af_vsock.c=2750=static const struct net_proto_family vsock_family_ops = {\nnet/vmw_vsock/af_vsock.c:2751:\t.family = AF_VSOCK,\nnet/vmw_vsock/af_vsock.c-2752-\t.create = vsock_create,\n--\nnet/vmw_vsock/af_vsock.c=2813=static int __vsock_net_mode_string(const struct ctl_table *table, int write,\n--\nnet/vmw_vsock/af_vsock.c-2817-{\nnet/vmw_vsock/af_vsock.c:2818:\tchar data[VSOCK_NET_MODE_STR_MAX] = {0};\nnet/vmw_vsock/af_vsock.c-2819-\tstruct ctl_table tmp;\n--\nnet/vmw_vsock/af_vsock.c-2833-\t\tswitch (mode) {\nnet/vmw_vsock/af_vsock.c:2834:\t\tcase VSOCK_NET_MODE_GLOBAL:\nnet/vmw_vsock/af_vsock.c:2835:\t\t\tp = VSOCK_NET_MODE_STR_GLOBAL;\nnet/vmw_vsock/af_vsock.c-2836-\t\t\tbreak;\nnet/vmw_vsock/af_vsock.c:2837:\t\tcase VSOCK_NET_MODE_LOCAL:\nnet/vmw_vsock/af_vsock.c:2838:\t\t\tp = VSOCK_NET_MODE_STR_LOCAL;\nnet/vmw_vsock/af_vsock.c-2839-\t\t\tbreak;\n--\nnet/vmw_vsock/af_vsock.c-2856-\nnet/vmw_vsock/af_vsock.c:2857:\tif (!strncmp(data, VSOCK_NET_MODE_STR_GLOBAL, sizeof(data)))\nnet/vmw_vsock/af_vsock.c:2858:\t\t*new_mode = VSOCK_NET_MODE_GLOBAL;\nnet/vmw_vsock/af_vsock.c:2859:\telse if (!strncmp(data, VSOCK_NET_MODE_STR_LOCAL, sizeof(data)))\nnet/vmw_vsock/af_vsock.c:2860:\t\t*new_mode = VSOCK_NET_MODE_LOCAL;\nnet/vmw_vsock/af_vsock.c-2861-\telse\n--\nnet/vmw_vsock/af_vsock.c=2881=static int vsock_net_child_mode_string(const struct ctl_table *table, int write,\n--\nnet/vmw_vsock/af_vsock.c-2898-\t\t */\nnet/vmw_vsock/af_vsock.c:2899:\t\tif (vsock_net_mode(net) == VSOCK_NET_MODE_LOCAL \u0026\u0026\nnet/vmw_vsock/af_vsock.c:2900:\t\t    new_mode == VSOCK_NET_MODE_GLOBAL)\nnet/vmw_vsock/af_vsock.c-2901-\t\t\treturn -EPERM;\n--\nnet/vmw_vsock/af_vsock.c=2910=static const struct ctl_table vsock_table[] = {\n--\nnet/vmw_vsock/af_vsock.c-2913-\t\t.data\t\t= \u0026init_net.vsock.mode,\nnet/vmw_vsock/af_vsock.c:2914:\t\t.maxlen\t\t= VSOCK_NET_MODE_STR_MAX,\nnet/vmw_vsock/af_vsock.c-2915-\t\t.mode\t\t= 0444,\n--\nnet/vmw_vsock/af_vsock.c-2920-\t\t.data\t\t= \u0026init_net.vsock.child_ns_mode,\nnet/vmw_vsock/af_vsock.c:2921:\t\t.maxlen\t\t= VSOCK_NET_MODE_STR_MAX,\nnet/vmw_vsock/af_vsock.c-2922-\t\t.mode\t\t= 0644,\n--\nnet/vmw_vsock/af_vsock.c=2987=static void vsock_net_init(struct net *net)\n--\nnet/vmw_vsock/af_vsock.c-2989-\tif (net_eq(net, \u0026init_net))\nnet/vmw_vsock/af_vsock.c:2990:\t\tnet-\u003evsock.mode = VSOCK_NET_MODE_GLOBAL;\nnet/vmw_vsock/af_vsock.c-2991-\telse\n--\nnet/vmw_vsock/af_vsock.c=3019=static int __init vsock_init(void)\n--\nnet/vmw_vsock/af_vsock.c-3041-\t\tpr_err(\"could not register af_vsock (%d) address family: %d\\n\",\nnet/vmw_vsock/af_vsock.c:3042:\t\t       AF_VSOCK, err);\nnet/vmw_vsock/af_vsock.c-3043-\t\tgoto err_unregister_proto;\n--\nnet/vmw_vsock/af_vsock.c-3055-err_unregister_sock:\nnet/vmw_vsock/af_vsock.c:3056:\tsock_unregister(AF_VSOCK);\nnet/vmw_vsock/af_vsock.c-3057-err_unregister_proto:\n--\nnet/vmw_vsock/af_vsock.c=3065=static void __exit vsock_exit(void)\n--\nnet/vmw_vsock/af_vsock.c-3067-\tmisc_deregister(\u0026vsock_device);\nnet/vmw_vsock/af_vsock.c:3068:\tsock_unregister(AF_VSOCK);\nnet/vmw_vsock/af_vsock.c-3069-\tproto_unregister(\u0026vsock_proto);\n--\nnet/vmw_vsock/af_vsock.c=3079=int vsock_core_register(const struct vsock_transport *t, int features)\n--\nnet/vmw_vsock/af_vsock.c-3091-\nnet/vmw_vsock/af_vsock.c:3092:\tif (features \u0026 VSOCK_TRANSPORT_F_H2G) {\nnet/vmw_vsock/af_vsock.c-3093-\t\tif (t_h2g) {\n--\nnet/vmw_vsock/af_vsock.c-3099-\nnet/vmw_vsock/af_vsock.c:3100:\tif (features \u0026 VSOCK_TRANSPORT_F_G2H) {\nnet/vmw_vsock/af_vsock.c-3101-\t\tif (t_g2h) {\n--\nnet/vmw_vsock/af_vsock.c-3107-\nnet/vmw_vsock/af_vsock.c:3108:\tif (features \u0026 VSOCK_TRANSPORT_F_DGRAM) {\nnet/vmw_vsock/af_vsock.c-3109-\t\tif (t_dgram) {\n--\nnet/vmw_vsock/af_vsock.c-3115-\nnet/vmw_vsock/af_vsock.c:3116:\tif (features \u0026 VSOCK_TRANSPORT_F_LOCAL) {\nnet/vmw_vsock/af_vsock.c-3117-\t\tif (t_local) {\n--\nnet/vmw_vsock/af_vsock_tap.c-2-/*\nnet/vmw_vsock/af_vsock_tap.c:3: * Tap functions for AF_VSOCK sockets.\nnet/vmw_vsock/af_vsock_tap.c-4- *\n--\nnet/vmw_vsock/af_vsock_tap.c=17=int vsock_add_tap(struct vsock_tap *vt)\nnet/vmw_vsock/af_vsock_tap.c-18-{\nnet/vmw_vsock/af_vsock_tap.c:19:\tif (unlikely(vt-\u003edev-\u003etype != ARPHRD_VSOCKMON))\nnet/vmw_vsock/af_vsock_tap.c-20-\t\treturn -EINVAL;\n--\nnet/vmw_vsock/diag.c=14=static int sk_diag_fill(struct sock *sk, struct sk_buff *skb,\n--\nnet/vmw_vsock/diag.c-26-\trep = nlmsg_data(nlh);\nnet/vmw_vsock/diag.c:27:\trep-\u003evdiag_family = AF_VSOCK;\nnet/vmw_vsock/diag.c-28-\n--\nnet/vmw_vsock/diag.c=159=static const struct sock_diag_handler vsock_diag_handler = {\nnet/vmw_vsock/diag.c-160-\t.owner = THIS_MODULE,\nnet/vmw_vsock/diag.c:161:\t.family = AF_VSOCK,\nnet/vmw_vsock/diag.c-162-\t.dump = vsock_diag_handler_dump,\n--\nnet/vmw_vsock/diag.c=179=MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG,\nnet/vmw_vsock/diag.c:180:\t\t\t       40 /* AF_VSOCK */);\n--\nnet/vmw_vsock/hyperv_transport.c=94=struct hvsock {\n--\nnet/vmw_vsock/hyperv_transport.c-111-\nnet/vmw_vsock/hyperv_transport.c:112:/* In the VM, we support Hyper-V Sockets with AF_VSOCK, and the endpoint is\nnet/vmw_vsock/hyperv_transport.c-113- * \u003ccid, port\u003e (see struct sockaddr_vm). Note: cid is not really used here:\n--\nnet/vmw_vsock/hyperv_transport.c-135- *\nnet/vmw_vsock/hyperv_transport.c:136: * To make use of the AF_VSOCK infrastructure in Linux VM, we have to limit\nnet/vmw_vsock/hyperv_transport.c-137- * the available GUID space of SOCKADDR_HV so that we can create a mapping\nnet/vmw_vsock/hyperv_transport.c:138: * between AF_VSOCK port and SOCKADDR_HV Service GUID. The rule of writing\nnet/vmw_vsock/hyperv_transport.c-139- * Hyper-V Sockets apps on the host and in Linux VM is:\n--\nnet/vmw_vsock/hyperv_transport.c=960=static int __init hvs_init(void)\n--\nnet/vmw_vsock/hyperv_transport.c-967-\nnet/vmw_vsock/hyperv_transport.c:968:\tret = vsock_core_register(\u0026hvs_transport, VSOCK_TRANSPORT_F_G2H);\nnet/vmw_vsock/hyperv_transport.c-969-\tif (ret) {\n--\nnet/vmw_vsock/hyperv_transport.c=988=MODULE_LICENSE(\"GPL\");\nnet/vmw_vsock/hyperv_transport.c:989:MODULE_ALIAS_NETPROTO(PF_VSOCK);\n--\nnet/vmw_vsock/virtio_transport.c=30=struct virtio_vsock {\nnet/vmw_vsock/virtio_transport.c-31-\tstruct virtio_device *vdev;\nnet/vmw_vsock/virtio_transport.c:32:\tstruct virtqueue *vqs[VSOCK_VQ_MAX];\nnet/vmw_vsock/virtio_transport.c-33-\n--\nnet/vmw_vsock/virtio_transport.c-38-\nnet/vmw_vsock/virtio_transport.c:39:\t/* The following fields are protected by tx_lock.  vqs[VSOCK_VQ_TX]\nnet/vmw_vsock/virtio_transport.c-40-\t * must be accessed with tx_lock held.\n--\nnet/vmw_vsock/virtio_transport.c-49-\nnet/vmw_vsock/virtio_transport.c:50:\t/* The following fields are protected by rx_lock.  vqs[VSOCK_VQ_RX]\nnet/vmw_vsock/virtio_transport.c-51-\t * must be accessed with rx_lock held.\n--\nnet/vmw_vsock/virtio_transport.c-72-\t/* The following fields are protected by event_lock.\nnet/vmw_vsock/virtio_transport.c:73:\t * vqs[VSOCK_VQ_EVENT] must be accessed with event_lock held.\nnet/vmw_vsock/virtio_transport.c-74-\t */\n--\nnet/vmw_vsock/virtio_transport.c=158=virtio_transport_send_pkt_work(struct work_struct *work)\n--\nnet/vmw_vsock/virtio_transport.c-170-\nnet/vmw_vsock/virtio_transport.c:171:\tvq = vsock-\u003evqs[VSOCK_VQ_TX];\nnet/vmw_vsock/virtio_transport.c-172-\n--\nnet/vmw_vsock/virtio_transport.c-190-\t\tif (reply) {\nnet/vmw_vsock/virtio_transport.c:191:\t\t\tstruct virtqueue *rx_vq = vsock-\u003evqs[VSOCK_VQ_RX];\nnet/vmw_vsock/virtio_transport.c-192-\t\t\tint val;\n--\nnet/vmw_vsock/virtio_transport.c=217=static int virtio_transport_send_skb_fast_path(struct virtio_vsock *vsock, struct sk_buff *skb)\nnet/vmw_vsock/virtio_transport.c-218-{\nnet/vmw_vsock/virtio_transport.c:219:\tstruct virtqueue *vq = vsock-\u003evqs[VSOCK_VQ_TX];\nnet/vmw_vsock/virtio_transport.c-220-\tint ret;\n--\nnet/vmw_vsock/virtio_transport.c=280=virtio_transport_cancel_pkt(struct vsock_sock *vsk)\n--\nnet/vmw_vsock/virtio_transport.c-294-\tif (cnt) {\nnet/vmw_vsock/virtio_transport.c:295:\t\tstruct virtqueue *rx_vq = vsock-\u003evqs[VSOCK_VQ_RX];\nnet/vmw_vsock/virtio_transport.c-296-\t\tint new_cnt;\n--\nnet/vmw_vsock/virtio_transport.c=311=static void virtio_vsock_rx_fill(struct virtio_vsock *vsock)\nnet/vmw_vsock/virtio_transport.c-312-{\nnet/vmw_vsock/virtio_transport.c:313:\tint total_len = VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE;\nnet/vmw_vsock/virtio_transport.c-314-\tstruct scatterlist pkt, *p;\n--\nnet/vmw_vsock/virtio_transport.c-318-\nnet/vmw_vsock/virtio_transport.c:319:\tvq = vsock-\u003evqs[VSOCK_VQ_RX];\nnet/vmw_vsock/virtio_transport.c-320-\n--\nnet/vmw_vsock/virtio_transport.c-325-\nnet/vmw_vsock/virtio_transport.c:326:\t\tmemset(skb-\u003ehead, 0, VIRTIO_VSOCK_SKB_HEADROOM);\nnet/vmw_vsock/virtio_transport.c-327-\t\tsg_init_one(\u0026pkt, virtio_vsock_hdr(skb), total_len);\n--\nnet/vmw_vsock/virtio_transport.c=342=static void virtio_transport_tx_work(struct work_struct *work)\n--\nnet/vmw_vsock/virtio_transport.c-353-\nnet/vmw_vsock/virtio_transport.c:354:\tvq = vsock-\u003evqs[VSOCK_VQ_TX];\nnet/vmw_vsock/virtio_transport.c-355-\n--\nnet/vmw_vsock/virtio_transport.c=375=static bool virtio_transport_more_replies(struct virtio_vsock *vsock)\nnet/vmw_vsock/virtio_transport.c-376-{\nnet/vmw_vsock/virtio_transport.c:377:\tstruct virtqueue *vq = vsock-\u003evqs[VSOCK_VQ_RX];\nnet/vmw_vsock/virtio_transport.c-378-\tint val;\n--\nnet/vmw_vsock/virtio_transport.c=387=static int virtio_vsock_event_fill_one(struct virtio_vsock *vsock,\n--\nnet/vmw_vsock/virtio_transport.c-392-\nnet/vmw_vsock/virtio_transport.c:393:\tvq = vsock-\u003evqs[VSOCK_VQ_EVENT];\nnet/vmw_vsock/virtio_transport.c-394-\n--\nnet/vmw_vsock/virtio_transport.c=401=static void virtio_vsock_event_fill(struct virtio_vsock *vsock)\n--\nnet/vmw_vsock/virtio_transport.c-410-\nnet/vmw_vsock/virtio_transport.c:411:\tvirtqueue_kick(vsock-\u003evqs[VSOCK_VQ_EVENT]);\nnet/vmw_vsock/virtio_transport.c-412-}\n--\nnet/vmw_vsock/virtio_transport.c=437=static void virtio_vsock_event_handle(struct virtio_vsock *vsock,\n--\nnet/vmw_vsock/virtio_transport.c-440-\tswitch (le32_to_cpu(event-\u003eid)) {\nnet/vmw_vsock/virtio_transport.c:441:\tcase VIRTIO_VSOCK_EVENT_TRANSPORT_RESET:\nnet/vmw_vsock/virtio_transport.c-442-\t\tvirtio_vsock_update_guest_cid(vsock);\n--\nnet/vmw_vsock/virtio_transport.c=449=static void virtio_transport_event_work(struct work_struct *work)\n--\nnet/vmw_vsock/virtio_transport.c-459-\nnet/vmw_vsock/virtio_transport.c:460:\tvq = vsock-\u003evqs[VSOCK_VQ_EVENT];\nnet/vmw_vsock/virtio_transport.c-461-\n--\nnet/vmw_vsock/virtio_transport.c-474-\nnet/vmw_vsock/virtio_transport.c:475:\tvirtqueue_kick(vsock-\u003evqs[VSOCK_VQ_EVENT]);\nnet/vmw_vsock/virtio_transport.c-476-out:\n--\nnet/vmw_vsock/virtio_transport.c=507=static bool virtio_transport_can_msgzerocopy(int bufs_num)\n--\nnet/vmw_vsock/virtio_transport.c-515-\tif (vsock) {\nnet/vmw_vsock/virtio_transport.c:516:\t\tstruct virtqueue *vq = vsock-\u003evqs[VSOCK_VQ_TX];\nnet/vmw_vsock/virtio_transport.c-517-\n--\nnet/vmw_vsock/virtio_transport.c=632=static void virtio_transport_rx_work(struct work_struct *work)\n--\nnet/vmw_vsock/virtio_transport.c-642-\nnet/vmw_vsock/virtio_transport.c:643:\tvq = vsock-\u003evqs[VSOCK_VQ_RX];\nnet/vmw_vsock/virtio_transport.c-644-\n--\nnet/vmw_vsock/virtio_transport.c=699=static int virtio_vsock_vqs_init(struct virtio_vsock *vsock)\n--\nnet/vmw_vsock/virtio_transport.c-715-\nnet/vmw_vsock/virtio_transport.c:716:\tret = virtio_find_vqs(vdev, VSOCK_VQ_MAX, vsock-\u003evqs, vqs_info, NULL);\nnet/vmw_vsock/virtio_transport.c-717-\tif (ret \u003c 0)\n--\nnet/vmw_vsock/virtio_transport.c=755=static void virtio_vsock_vqs_del(struct virtio_vsock *vsock)\n--\nnet/vmw_vsock/virtio_transport.c-784-\tmutex_lock(\u0026vsock-\u003erx_lock);\nnet/vmw_vsock/virtio_transport.c:785:\twhile ((skb = virtqueue_detach_unused_buf(vsock-\u003evqs[VSOCK_VQ_RX])))\nnet/vmw_vsock/virtio_transport.c-786-\t\tkfree_skb(skb);\n--\nnet/vmw_vsock/virtio_transport.c-789-\tmutex_lock(\u0026vsock-\u003etx_lock);\nnet/vmw_vsock/virtio_transport.c:790:\twhile ((skb = virtqueue_detach_unused_buf(vsock-\u003evqs[VSOCK_VQ_TX])))\nnet/vmw_vsock/virtio_transport.c-791-\t\tkfree_skb(skb);\n--\nnet/vmw_vsock/virtio_transport.c=800=static int virtio_vsock_probe(struct virtio_device *vdev)\n--\nnet/vmw_vsock/virtio_transport.c-834-\nnet/vmw_vsock/virtio_transport.c:835:\tif (virtio_has_feature(vdev, VIRTIO_VSOCK_F_SEQPACKET))\nnet/vmw_vsock/virtio_transport.c-836-\t\tvsock-\u003eseqpacket_allow = true;\n--\nnet/vmw_vsock/virtio_transport.c=929=static struct virtio_device_id id_table[] = {\nnet/vmw_vsock/virtio_transport.c:930:\t{ VIRTIO_ID_VSOCK, VIRTIO_DEV_ANY_ID },\nnet/vmw_vsock/virtio_transport.c-931-\t{ 0 },\n--\nnet/vmw_vsock/virtio_transport.c=934=static unsigned int features[] = {\nnet/vmw_vsock/virtio_transport.c:935:\tVIRTIO_VSOCK_F_SEQPACKET\nnet/vmw_vsock/virtio_transport.c-936-};\n--\nnet/vmw_vsock/virtio_transport.c=951=static int __init virtio_vsock_init(void)\n--\nnet/vmw_vsock/virtio_transport.c-959-\tret = vsock_core_register(\u0026virtio_transport.transport,\nnet/vmw_vsock/virtio_transport.c:960:\t\t\t\t  VSOCK_TRANSPORT_F_G2H);\nnet/vmw_vsock/virtio_transport.c-961-\tif (ret)\n--\nnet/vmw_vsock/virtio_transport_common.c-23-/* How long to wait for graceful shutdown of a connection */\nnet/vmw_vsock/virtio_transport_common.c:24:#define VSOCK_CLOSE_TIMEOUT (8 * HZ)\nnet/vmw_vsock/virtio_transport_common.c-25-\n--\nnet/vmw_vsock/virtio_transport_common.c-33-#define MAX_COLLAPSE_LEN \\\nnet/vmw_vsock/virtio_transport_common.c:34:\tSKB_MAX_ORDER(VIRTIO_VSOCK_SKB_HEADROOM, PAGE_ALLOC_COSTLY_ORDER)\nnet/vmw_vsock/virtio_transport_common.c-35-\n--\nnet/vmw_vsock/virtio_transport_common.c=119=static struct sk_buff *virtio_transport_build_skb(void *opaque)\n--\nnet/vmw_vsock/virtio_transport_common.c-146-\nnet/vmw_vsock/virtio_transport_common.c:147:\thdr-\u003etransport = cpu_to_le16(AF_VSOCK_TRANSPORT_VIRTIO);\nnet/vmw_vsock/virtio_transport_common.c-148-\thdr-\u003elen = cpu_to_le16(sizeof(*pkt_hdr));\n--\nnet/vmw_vsock/virtio_transport_common.c-151-\tswitch (le16_to_cpu(pkt_hdr-\u003eop)) {\nnet/vmw_vsock/virtio_transport_common.c:152:\tcase VIRTIO_VSOCK_OP_REQUEST:\nnet/vmw_vsock/virtio_transport_common.c:153:\tcase VIRTIO_VSOCK_OP_RESPONSE:\nnet/vmw_vsock/virtio_transport_common.c:154:\t\thdr-\u003eop = cpu_to_le16(AF_VSOCK_OP_CONNECT);\nnet/vmw_vsock/virtio_transport_common.c-155-\t\tbreak;\nnet/vmw_vsock/virtio_transport_common.c:156:\tcase VIRTIO_VSOCK_OP_RST:\nnet/vmw_vsock/virtio_transport_common.c:157:\tcase VIRTIO_VSOCK_OP_SHUTDOWN:\nnet/vmw_vsock/virtio_transport_common.c:158:\t\thdr-\u003eop = cpu_to_le16(AF_VSOCK_OP_DISCONNECT);\nnet/vmw_vsock/virtio_transport_common.c-159-\t\tbreak;\nnet/vmw_vsock/virtio_transport_common.c:160:\tcase VIRTIO_VSOCK_OP_RW:\nnet/vmw_vsock/virtio_transport_common.c:161:\t\thdr-\u003eop = cpu_to_le16(AF_VSOCK_OP_PAYLOAD);\nnet/vmw_vsock/virtio_transport_common.c-162-\t\tbreak;\nnet/vmw_vsock/virtio_transport_common.c:163:\tcase VIRTIO_VSOCK_OP_CREDIT_UPDATE:\nnet/vmw_vsock/virtio_transport_common.c:164:\tcase VIRTIO_VSOCK_OP_CREDIT_REQUEST:\nnet/vmw_vsock/virtio_transport_common.c:165:\t\thdr-\u003eop = cpu_to_le16(AF_VSOCK_OP_CONTROL);\nnet/vmw_vsock/virtio_transport_common.c-166-\t\tbreak;\nnet/vmw_vsock/virtio_transport_common.c-167-\tdefault:\nnet/vmw_vsock/virtio_transport_common.c:168:\t\thdr-\u003eop = cpu_to_le16(AF_VSOCK_OP_UNKNOWN);\nnet/vmw_vsock/virtio_transport_common.c-169-\t\tbreak;\n--\nnet/vmw_vsock/virtio_transport_common.c-182-\nnet/vmw_vsock/virtio_transport_common.c:183:\t\tif (skb_copy_datagram_iter(pkt, VIRTIO_VSOCK_SKB_CB(pkt)-\u003eoffset,\nnet/vmw_vsock/virtio_transport_common.c-184-\t\t\t\t\t   \u0026iov_iter, payload_len)) {\n--\nnet/vmw_vsock/virtio_transport_common.c=203=static u16 virtio_transport_get_type(struct sock *sk)\n--\nnet/vmw_vsock/virtio_transport_common.c-205-\tif (sk-\u003esk_type == SOCK_STREAM)\nnet/vmw_vsock/virtio_transport_common.c:206:\t\treturn VIRTIO_VSOCK_TYPE_STREAM;\nnet/vmw_vsock/virtio_transport_common.c-207-\telse\nnet/vmw_vsock/virtio_transport_common.c:208:\t\treturn VIRTIO_VSOCK_TYPE_SEQPACKET;\nnet/vmw_vsock/virtio_transport_common.c-209-}\n--\nnet/vmw_vsock/virtio_transport_common.c=212=static struct sk_buff *virtio_transport_alloc_skb(struct virtio_vsock_pkt_info *info,\n--\nnet/vmw_vsock/virtio_transport_common.c-224-\nnet/vmw_vsock/virtio_transport_common.c:225:\tskb_len = VIRTIO_VSOCK_SKB_HEADROOM;\nnet/vmw_vsock/virtio_transport_common.c-226-\n--\nnet/vmw_vsock/virtio_transport_common.c-241-\t * setting skb owner in 'skb_set_owner_w()'. The only case\nnet/vmw_vsock/virtio_transport_common.c:242:\t * when 'vsk' == NULL is VIRTIO_VSOCK_OP_RST control message\nnet/vmw_vsock/virtio_transport_common.c-243-\t * without payload.\n--\nnet/vmw_vsock/virtio_transport_common.c-266-\t\tif (msg_data_left(info-\u003emsg) == 0 \u0026\u0026\nnet/vmw_vsock/virtio_transport_common.c:267:\t\t    info-\u003etype == VIRTIO_VSOCK_TYPE_SEQPACKET) {\nnet/vmw_vsock/virtio_transport_common.c-268-\t\t\tstruct virtio_vsock_hdr *hdr = virtio_vsock_hdr(skb);\n\n"
}

gemini-3.7-flash

null

null

							input: 17436
							output: 32
							thoughts: 492
						

**Analysis of the vsock_connect Patch**

Okay, let's break this down. We're looking at a patch impacting `net/vmw_vsock/af_vsock.c`, specifically when `CONFIG_VSOCKETS` is enabled. My immediate concern is, what's changed, and how critical is it?

The only function modified is `vsock_connect`. Let's see how `vsock_connect` is called. Ah, right, in `af_vsock.c` itself. The `vsock_stream_ops` and `vsock_seqpacket_ops` structures define `.connect = vsock_connect`. So, a user-space `connect()` system call eventually hits this function, as expected.

Now, what's the patch *doing* in `vsock_connect`? I see two primary changes:

1.  It's altering the state check. The original code broke out of the connection attempt if the socket was already `TCP_ESTABLISHED`. Now, it also breaks if the socket is `TCP_CLOSING`. Hmmm, looks like they're trying to handle `TCP_CLOSING` states more gracefully.
2.  It's altering the error handling logic. It used to check for an error and transition to `TCP_CLOSE` if there was one. Now, the transition to `TCP_CLOSE` only happens *if* there's an error *and* the socket isn't already `TCP_ESTABLISHED` or `TCP_CLOSING`. This implies they're trying to prevent premature socket closure in certain connection scenarios.

So, this patch changes socket state transitions within `vsock_connect`. Given that AF_VSOCK is core networking code, and it's fully reachable in virtualized environments like QEMU with virtio-vsock or vsock_loopback. Also, since Syzkaller is actively testing this with various socket calls including `connect()`, the scope of the potential impact is significant. It's core, reachable networking code and could potentially affect stability and error handling.

Therefore, worth fuzzing? Absolutely, **true**!

Now, for FocusSymbols, `vsock_connect` is the key. Is there anything else modified? I need to check the rest of `af_vsock.c` and related files, but the patch seems focused solely on `vsock_connect`. Now let's see what the callers are within `af_vsock.c`.

{
  "Expression": "vsock_connect",
  "PathPrefix": "net/vmw_vsock/"
}

{
  "Output": "net/vmw_vsock/af_vsock.c=209=static DEFINE_MUTEX(vsock_register_mutex);\n--\nnet/vmw_vsock/af_vsock.c-235-\t(((src)-\u003esvm_cid ^ (dst)-\u003esvm_port) % VSOCK_HASH_SIZE)\nnet/vmw_vsock/af_vsock.c:236:#define vsock_connected_sockets(src, dst)\t\t\\\nnet/vmw_vsock/af_vsock.c:237:\t(\u0026vsock_connected_table[VSOCK_CONN_HASH(src, dst)])\nnet/vmw_vsock/af_vsock.c:238:#define vsock_connected_sockets_vsk(vsk)\t\t\t\t\\\nnet/vmw_vsock/af_vsock.c:239:\tvsock_connected_sockets(\u0026(vsk)-\u003eremote_addr, \u0026(vsk)-\u003elocal_addr)\nnet/vmw_vsock/af_vsock.c-240-\n--\nnet/vmw_vsock/af_vsock.c=242=EXPORT_SYMBOL_GPL(vsock_bind_table);\nnet/vmw_vsock/af_vsock.c:243:struct list_head vsock_connected_table[VSOCK_HASH_SIZE];\nnet/vmw_vsock/af_vsock.c:244:EXPORT_SYMBOL_GPL(vsock_connected_table);\nnet/vmw_vsock/af_vsock.c-245-DEFINE_SPINLOCK(vsock_table_lock);\n--\nnet/vmw_vsock/af_vsock.c=260=static void vsock_init_tables(void)\n--\nnet/vmw_vsock/af_vsock.c-266-\nnet/vmw_vsock/af_vsock.c:267:\tfor (i = 0; i \u003c ARRAY_SIZE(vsock_connected_table); i++)\nnet/vmw_vsock/af_vsock.c:268:\t\tINIT_LIST_HEAD(\u0026vsock_connected_table[i]);\nnet/vmw_vsock/af_vsock.c-269-}\n--\nnet/vmw_vsock/af_vsock.c=320=__vsock_find_connected_socket_net(struct sockaddr_vm *src,\n--\nnet/vmw_vsock/af_vsock.c-324-\nnet/vmw_vsock/af_vsock.c:325:\tlist_for_each_entry(vsk, vsock_connected_sockets(src, dst),\nnet/vmw_vsock/af_vsock.c-326-\t\t\t    connected_table) {\n--\nnet/vmw_vsock/af_vsock.c=346=void vsock_insert_connected(struct vsock_sock *vsk)\nnet/vmw_vsock/af_vsock.c-347-{\nnet/vmw_vsock/af_vsock.c:348:\tstruct list_head *list = vsock_connected_sockets(\nnet/vmw_vsock/af_vsock.c-349-\t\t\u0026vsk-\u003eremote_addr, \u0026vsk-\u003elocal_addr);\n--\nnet/vmw_vsock/af_vsock.c=483=void vsock_for_each_connected_socket(struct vsock_transport *transport,\n--\nnet/vmw_vsock/af_vsock.c-489-\nnet/vmw_vsock/af_vsock.c:490:\tfor (i = 0; i \u003c ARRAY_SIZE(vsock_connected_table); i++) {\nnet/vmw_vsock/af_vsock.c-491-\t\tstruct vsock_sock *vsk;\nnet/vmw_vsock/af_vsock.c:492:\t\tlist_for_each_entry(vsk, \u0026vsock_connected_table[i],\nnet/vmw_vsock/af_vsock.c-493-\t\t\t\t    connected_table) {\n--\nnet/vmw_vsock/af_vsock.c=599=int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)\n--\nnet/vmw_vsock/af_vsock.c-672-\t\t/* transport-\u003erelease() must be called with sock lock acquired.\nnet/vmw_vsock/af_vsock.c:673:\t\t * This path can only be taken during vsock_connect(), where we\nnet/vmw_vsock/af_vsock.c-674-\t\t * have already held the sock lock. In the other cases, this\n--\nnet/vmw_vsock/af_vsock.c-682-\t\t * state, since we are reassigning the socket to a new transport\nnet/vmw_vsock/af_vsock.c:683:\t\t * during vsock_connect(), let's reset these fields to have a\nnet/vmw_vsock/af_vsock.c-684-\t\t * clean state.\n--\nnet/vmw_vsock/af_vsock.c=897=static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr)\n--\nnet/vmw_vsock/af_vsock.c-933-\nnet/vmw_vsock/af_vsock.c:934:static void vsock_connect_timeout(struct work_struct *work);\nnet/vmw_vsock/af_vsock.c-935-\nnet/vmw_vsock/af_vsock.c=936=static struct sock *__vsock_create(struct net *net,\n--\nnet/vmw_vsock/af_vsock.c-975-\tWRITE_ONCE(vsk-\u003epeer_shutdown, 0);\nnet/vmw_vsock/af_vsock.c:976:\tINIT_DELAYED_WORK(\u0026vsk-\u003econnect_work, vsock_connect_timeout);\nnet/vmw_vsock/af_vsock.c-977-\tINIT_DELAYED_WORK(\u0026vsk-\u003epending_work, vsock_pending_work);\n--\nnet/vmw_vsock/af_vsock.c=1090=EXPORT_SYMBOL_GPL(vsock_stream_has_data);\nnet/vmw_vsock/af_vsock.c-1091-\nnet/vmw_vsock/af_vsock.c:1092:s64 vsock_connectible_has_data(struct vsock_sock *vsk)\nnet/vmw_vsock/af_vsock.c-1093-{\n--\nnet/vmw_vsock/af_vsock.c-1103-}\nnet/vmw_vsock/af_vsock.c:1104:EXPORT_SYMBOL_GPL(vsock_connectible_has_data);\nnet/vmw_vsock/af_vsock.c-1105-\n--\nnet/vmw_vsock/af_vsock.c=1672=static int vsock_transport_cancel_pkt(struct vsock_sock *vsk)\n--\nnet/vmw_vsock/af_vsock.c-1681-\nnet/vmw_vsock/af_vsock.c:1682:static void vsock_connect_timeout(struct work_struct *work)\nnet/vmw_vsock/af_vsock.c-1683-{\n--\nnet/vmw_vsock/af_vsock.c-1703-\nnet/vmw_vsock/af_vsock.c:1704:static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,\nnet/vmw_vsock/af_vsock.c-1705-\t\t\t int addr_len, int flags)\n--\nnet/vmw_vsock/af_vsock.c=1996=static void vsock_update_buffer_size(struct vsock_sock *vsk,\n--\nnet/vmw_vsock/af_vsock.c-2012-\nnet/vmw_vsock/af_vsock.c:2013:static int vsock_connectible_setsockopt(struct socket *sock,\nnet/vmw_vsock/af_vsock.c-2014-\t\t\t\t\tint level,\n--\nnet/vmw_vsock/af_vsock.c-2126-\nnet/vmw_vsock/af_vsock.c:2127:static int vsock_connectible_getsockopt(struct socket *sock,\nnet/vmw_vsock/af_vsock.c-2128-\t\t\t\t\tint level, int optname,\n--\nnet/vmw_vsock/af_vsock.c-2185-\nnet/vmw_vsock/af_vsock.c:2186:static int vsock_connectible_sendmsg(struct socket *sock, struct msghdr *msg,\nnet/vmw_vsock/af_vsock.c-2187-\t\t\t\t     size_t len)\n--\nnet/vmw_vsock/af_vsock.c-2347-\nnet/vmw_vsock/af_vsock.c:2348:static int vsock_connectible_wait_data(struct sock *sk,\nnet/vmw_vsock/af_vsock.c-2349-\t\t\t\t       struct wait_queue_entry *wait,\n--\nnet/vmw_vsock/af_vsock.c-2364-\t\tprepare_to_wait(sk_sleep(sk), wait, TASK_INTERRUPTIBLE);\nnet/vmw_vsock/af_vsock.c:2365:\t\tdata = vsock_connectible_has_data(vsk);\nnet/vmw_vsock/af_vsock.c-2366-\t\tif (data != 0)\n--\nnet/vmw_vsock/af_vsock.c=2415=static int __vsock_stream_recvmsg(struct sock *sk, struct msghdr *msg,\n--\nnet/vmw_vsock/af_vsock.c-2452-\nnet/vmw_vsock/af_vsock.c:2453:\t\terr = vsock_connectible_wait_data(sk, \u0026wait, timeout,\nnet/vmw_vsock/af_vsock.c-2454-\t\t\t\t\t\t  \u0026recv_data, target);\n--\nnet/vmw_vsock/af_vsock.c=2494=static int __vsock_seqpacket_recvmsg(struct sock *sk, struct msghdr *msg,\n--\nnet/vmw_vsock/af_vsock.c-2508-\nnet/vmw_vsock/af_vsock.c:2509:\terr = vsock_connectible_wait_data(sk, \u0026wait, timeout, NULL, 0);\nnet/vmw_vsock/af_vsock.c-2510-\tif (err \u003c= 0)\n--\nnet/vmw_vsock/af_vsock.c=2544=int\nnet/vmw_vsock/af_vsock.c:2545:__vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,\nnet/vmw_vsock/af_vsock.c-2546-\t\t\t    int flags)\n--\nnet/vmw_vsock/af_vsock.c=2611=int\nnet/vmw_vsock/af_vsock.c:2612:vsock_connectible_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,\nnet/vmw_vsock/af_vsock.c-2613-\t\t\t  int flags)\n--\nnet/vmw_vsock/af_vsock.c-2623-\nnet/vmw_vsock/af_vsock.c:2624:\treturn __vsock_connectible_recvmsg(sock, msg, len, flags);\nnet/vmw_vsock/af_vsock.c-2625-}\nnet/vmw_vsock/af_vsock.c:2626:EXPORT_SYMBOL_GPL(vsock_connectible_recvmsg);\nnet/vmw_vsock/af_vsock.c-2627-\n--\nnet/vmw_vsock/af_vsock.c=2652=static const struct proto_ops vsock_stream_ops = {\n--\nnet/vmw_vsock/af_vsock.c-2656-\t.bind = vsock_bind,\nnet/vmw_vsock/af_vsock.c:2657:\t.connect = vsock_connect,\nnet/vmw_vsock/af_vsock.c-2658-\t.socketpair = sock_no_socketpair,\n--\nnet/vmw_vsock/af_vsock.c-2664-\t.shutdown = vsock_shutdown,\nnet/vmw_vsock/af_vsock.c:2665:\t.setsockopt = vsock_connectible_setsockopt,\nnet/vmw_vsock/af_vsock.c:2666:\t.getsockopt_iter = vsock_connectible_getsockopt,\nnet/vmw_vsock/af_vsock.c:2667:\t.sendmsg = vsock_connectible_sendmsg,\nnet/vmw_vsock/af_vsock.c:2668:\t.recvmsg = vsock_connectible_recvmsg,\nnet/vmw_vsock/af_vsock.c-2669-\t.mmap = sock_no_mmap,\n--\nnet/vmw_vsock/af_vsock.c=2674=static const struct proto_ops vsock_seqpacket_ops = {\n--\nnet/vmw_vsock/af_vsock.c-2678-\t.bind = vsock_bind,\nnet/vmw_vsock/af_vsock.c:2679:\t.connect = vsock_connect,\nnet/vmw_vsock/af_vsock.c-2680-\t.socketpair = sock_no_socketpair,\n--\nnet/vmw_vsock/af_vsock.c-2686-\t.shutdown = vsock_shutdown,\nnet/vmw_vsock/af_vsock.c:2687:\t.setsockopt = vsock_connectible_setsockopt,\nnet/vmw_vsock/af_vsock.c:2688:\t.getsockopt_iter = vsock_connectible_getsockopt,\nnet/vmw_vsock/af_vsock.c:2689:\t.sendmsg = vsock_connectible_sendmsg,\nnet/vmw_vsock/af_vsock.c:2690:\t.recvmsg = vsock_connectible_recvmsg,\nnet/vmw_vsock/af_vsock.c-2691-\t.mmap = sock_no_mmap,\n--\nnet/vmw_vsock/diag.c=48=static int vsock_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)\n--\nnet/vmw_vsock/diag.c-101-\t/* Connected table (accepted connections) */\nnet/vmw_vsock/diag.c:102:\twhile (bucket \u003c ARRAY_SIZE(vsock_connected_table)) {\nnet/vmw_vsock/diag.c:103:\t\tstruct list_head *head = \u0026vsock_connected_table[bucket];\nnet/vmw_vsock/diag.c-104-\n--\nnet/vmw_vsock/hyperv_transport.c=193=static int hvs_channel_readable_payload(struct vmbus_channel *chan)\n--\nnet/vmw_vsock/hyperv_transport.c-198-\t\t/* At least we have 1 byte to read. We don't need to return\nnet/vmw_vsock/hyperv_transport.c:199:\t\t * the exact readable bytes: see vsock_connectible_recvmsg() -\u003e\nnet/vmw_vsock/hyperv_transport.c-200-\t\t * vsock_stream_has_data().\n--\nnet/vmw_vsock/vsock_bpf.c=25=static bool vsock_has_data(struct sock *sk, struct sk_psock *psock)\n--\nnet/vmw_vsock/vsock_bpf.c-29-\nnet/vmw_vsock/vsock_bpf.c:30:\tret = vsock_connectible_has_data(vsk);\nnet/vmw_vsock/vsock_bpf.c-31-\tif (ret \u003e 0)\n--\nnet/vmw_vsock/vsock_bpf.c=61=static int __vsock_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int flags)\n--\nnet/vmw_vsock/vsock_bpf.c-66-\tif (sk-\u003esk_type == SOCK_STREAM || sk-\u003esk_type == SOCK_SEQPACKET)\nnet/vmw_vsock/vsock_bpf.c:67:\t\terr = __vsock_connectible_recvmsg(sock, msg, len, flags);\nnet/vmw_vsock/vsock_bpf.c-68-\telse if (sk-\u003esk_type == SOCK_DGRAM)\n"
}

gemini-3.7-flash

null

null

							input: 22920
							output: 121
							thoughts: 229
						

**My Analysis of the VSOCK Connection Patch**

Okay, let's break this down systematically. My immediate focus is on the `vsock_connect` and `vsock_connect_timeout` functions, especially since the patch specifically targets `vsock_connect`. My initial thought is to cross-reference this with the kernel configuration options to confirm the relevant features are enabled. I need to make sure `CONFIG_VSOCKETS` is enabled, as this is the primary enabler for `af_vsock.c`. Furthermore, I'll need to confirm that `CONFIG_VSOCKETS_LOOPBACK` or `CONFIG_VIRTIO_VSOCKETS` are also enabled, as these options provide the specific transports that utilize VSOCK. In essence, `VSOCKETS` is the crucial configuration enabling the core `af_vsock.c` module that houses the `vsock_connect` function.

Now, let's solidify the understanding. The provided context indicates this is worth fuzzing and that the important configurations are present. `VSOCKETS`, `VSOCKETS_LOOPBACK`, and `VIRTIO_VSOCKETS` are the relevant enabling configs. The `vsock_connect` function is the targeted symbol.

The reasoning provided clarifies the core impact: The patch directly modifies socket state checks within `vsock_connect`, specifically in relation to how the connection establishment proceeds and how socket errors are handled. The change avoids an unwanted state reset in certain error conditions when the socket state (`sk_state`) is `TCP_CLOSING`. This clearly affects the socket lifecycle management within the AF_VSOCK network address family. This is the crux of the issue.

Finally, having validated the analysis and confirmed the critical elements, it's time to invoke `set-results`.

{
  "EnableConfigs": [
    "VSOCKETS",
    "VSOCKETS_LOOPBACK",
    "VIRTIO_VSOCKETS"
  ],
  "FocusSymbols": [
    "vsock_connect"
  ],
  "Reasoning": "The patch modifies vsock_connect() in net/vmw_vsock/af_vsock.c, changing the state validation logic during connection establishment and error handling by accommodating the TCP_CLOSING socket state. This affects reachable AF_VSOCK socket lifecycle transitions and warrants fuzzing.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "VSOCKETS",
    "VSOCKETS_LOOPBACK",
    "VIRTIO_VSOCKETS"
  ],
  "FocusSymbols": [
    "vsock_connect"
  ],
  "Reasoning": "The patch modifies vsock_connect() in net/vmw_vsock/af_vsock.c, changing the state validation logic during connection establishment and error handling by accommodating the TCP_CLOSING socket state. This affects reachable AF_VSOCK socket lifecycle transitions and warrants fuzzing.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

core

null

{
  "KMSANReasoning": "The patch modifies state machine handling in vsock_connect() by treating TCP_CLOSING similarly to TCP_ESTABLISHED when checking sk-\u003esk_state upon waking from connection wait and error handling. This change affects socket control flow and state transitions only. It does not introduce any new allocations, modify buffer copying or sizing, touch uninitialized memory, or expose kernel structures/padding to userspace. Therefore, there are no uninitialized memory read or info-leak risks that would necessitate a dedicated KMSAN fuzzing session.",
  "NeedsKMSAN": false
}

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

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

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

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

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

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

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
Prefer calling several tools at the same time to save round-trips.


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

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 517ed47629540e82778f080a986641e7724e6161
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Sep 9 22:33:21 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index f840498b58afb..eec5dd6daebb1 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1834,23 +1834,20 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
 		timeout = schedule_timeout(timeout);
 		lock_sock(sk);
 
-		/* Connection established. Whatever happens to socket once we
-		 * release it, that's not connect()'s concern. No need to go
+		/* Connection was established. Whatever happens to socket once
+		 * we release it, that's not connect()'s concern. No need to go
 		 * into signal and timeout handling. Call it a day.
 		 *
 		 * Note that allowing to "reset" an already established socket
 		 * here is racy and insecure.
 		 */
-		if (sk->sk_state == TCP_ESTABLISHED)
+		if (sk->sk_state == TCP_ESTABLISHED ||
+		    sk->sk_state == TCP_CLOSING)
 			break;
 
 		/* If connection was _not_ established and a signal/timeout came
 		 * to be, we want the socket's state reset. User space may want
 		 * to retry.
-		 *
-		 * sk_state != TCP_ESTABLISHED implies that socket is not on
-		 * vsock_connected_table. We keep the binding and the transport
-		 * assigned.
 		 */
 		if (signal_pending(current) || timeout == 0) {
 			err = timeout == 0 ? -ETIMEDOUT : sock_intr_errno(timeout);
@@ -1875,7 +1872,8 @@ static int vsock_connect(struct socket *sock, struct sockaddr_unsized *addr,
 	}
 
 	err = sock_error(sk);
-	if (err) {
+	if (err &&
+	    sk->sk_state != TCP_ESTABLISHED && sk->sk_state != TCP_CLOSING) {
 		sk->sk_state = TCP_CLOSE;
 		sock->state = SS_UNCONNECTED;
 	}

gemini-3.7-flash

null

null

							input: 2470
							output: 44
							thoughts: 604
						

**Analyzing the Need for Dedicated KMSAN Fuzzing**

Okay, so I'm being asked if this kernel patch in `net/vmw_vsock/af_vsock.c` needs special KMSAN fuzzing, or if KASAN and standard fuzzing are sufficient. Right, let's break it down.

First, I need to understand what this patch does. It looks like it's in the `vsock_connect` function. The code block addresses some edge cases related to connection establishment, specifically handling timeouts and signals during the connection process. It appears the original code was missing a state check. They've updated this to allow established or closing sockets. Then we see an `err` check and a state transition back to `TCP_CLOSE`. The code now avoids the state check when the socket is in an established or closing state. It's essentially refining the error handling in the connection establishment flow. They are correcting socket state handling during connection timeouts and interrupts.

Now, considering the file path `net/vmw_vsock/af_vsock.c`, it's clear this is networking code, specifically for vsock, which is a virtual socket implementation typically used in virtualization environments. Networking code is often a target for fuzzing because it is complex, and can be subject to external input, which makes it a good place to trigger memory safety issues. The code itself touches on socket states and connection timeouts, which hints at potential race conditions and concurrency problems.

So, do we *need* dedicated KMSAN fuzzing? My gut says "probably not *just* for this". The patch itself doesn't scream "KMSAN vulnerability" to me. KASAN should be enough for basic memory safety checks and detecting use-after-free or double-free issues in this area. We can use standard fuzzing techniques. This is because KASAN is already enabled, so we will likely catch any common memory errors without dedicated KMSAN fuzzing. But I need to be more thorough, so I'll also consider this: if this vsock code is a critical component of a larger system, say a hypervisor, or if this function is commonly called with many external inputs, it may be worthwhile to investigate fuzzing and KMSAN. KMSAN is more specific for kernel memory safety. So, If I see some potential here, I can add it to the list. I'll need to know more about the broader system context to make a final call.

{
  "File": "net/vmw_vsock/af_vsock.c",
  "FirstLine": 1800,
  "LineCount": 100
}

{
  "Contents": "1800:\t\t/* The receive path will handle all communication until we are able to\n1801:\t\t * enter the connected state.  Here we wait for the connection to be\n1802:\t\t * completed or a notification of an error.\n1803:\t\t */\n1804:\t\ttimeout = vsk-\u003econnect_timeout;\n1805:\t\tprepare_to_wait(sk_sleep(sk), \u0026wait, TASK_INTERRUPTIBLE);\n1806:\t\n1807:\t\t/* If the socket is already closing or it is in an error state, there\n1808:\t\t * is no point in waiting.\n1809:\t\t */\n1810:\t\twhile (sk-\u003esk_state != TCP_ESTABLISHED \u0026\u0026\n1811:\t\t       sk-\u003esk_state != TCP_CLOSING \u0026\u0026 sk-\u003esk_err == 0) {\n1812:\t\t\tif (flags \u0026 O_NONBLOCK) {\n1813:\t\t\t\t/* If we're not going to block, we schedule a timeout\n1814:\t\t\t\t * function to generate a timeout on the connection\n1815:\t\t\t\t * attempt, in case the peer doesn't respond in a\n1816:\t\t\t\t * timely manner. We hold on to the socket until the\n1817:\t\t\t\t * timeout fires.\n1818:\t\t\t\t */\n1819:\t\t\t\tsock_hold(sk);\n1820:\t\n1821:\t\t\t\t/* If the timeout function is already scheduled,\n1822:\t\t\t\t * reschedule it, then ungrab the socket refcount to\n1823:\t\t\t\t * keep it balanced.\n1824:\t\t\t\t */\n1825:\t\t\t\tif (mod_delayed_work(system_percpu_wq, \u0026vsk-\u003econnect_work,\n1826:\t\t\t\t\t\t     timeout))\n1827:\t\t\t\t\tsock_put(sk);\n1828:\t\n1829:\t\t\t\t/* Skip ahead to preserve error code set above. */\n1830:\t\t\t\tgoto out_wait;\n1831:\t\t\t}\n1832:\t\n1833:\t\t\trelease_sock(sk);\n1834:\t\t\ttimeout = schedule_timeout(timeout);\n1835:\t\t\tlock_sock(sk);\n1836:\t\n1837:\t\t\t/* Connection was established. Whatever happens to socket once\n1838:\t\t\t * we release it, that's not connect()'s concern. No need to go\n1839:\t\t\t * into signal and timeout handling. Call it a day.\n1840:\t\t\t *\n1841:\t\t\t * Note that allowing to \"reset\" an already established socket\n1842:\t\t\t * here is racy and insecure.\n1843:\t\t\t */\n1844:\t\t\tif (sk-\u003esk_state == TCP_ESTABLISHED ||\n1845:\t\t\t    sk-\u003esk_state == TCP_CLOSING)\n1846:\t\t\t\tbreak;\n1847:\t\n1848:\t\t\t/* If connection was _not_ established and a signal/timeout came\n1849:\t\t\t * to be, we want the socket's state reset. User space may want\n1850:\t\t\t * to retry.\n1851:\t\t\t */\n1852:\t\t\tif (signal_pending(current) || timeout == 0) {\n1853:\t\t\t\terr = timeout == 0 ? -ETIMEDOUT : sock_intr_errno(timeout);\n1854:\t\n1855:\t\t\t\t/* Listener might have already responded with\n1856:\t\t\t\t * VIRTIO_VSOCK_OP_RESPONSE. Its handling expects our\n1857:\t\t\t\t * sk_state == TCP_SYN_SENT, which hereby we break.\n1858:\t\t\t\t * In such case VIRTIO_VSOCK_OP_RST will follow.\n1859:\t\t\t\t */\n1860:\t\t\t\tsk-\u003esk_state = TCP_CLOSE;\n1861:\t\t\t\tsock-\u003estate = SS_UNCONNECTED;\n1862:\t\n1863:\t\t\t\t/* Try to cancel VIRTIO_VSOCK_OP_REQUEST skb sent out by\n1864:\t\t\t\t * transport-\u003econnect().\n1865:\t\t\t\t */\n1866:\t\t\t\tvsock_transport_cancel_pkt(vsk);\n1867:\t\n1868:\t\t\t\tgoto out_wait;\n1869:\t\t\t}\n1870:\t\n1871:\t\t\tprepare_to_wait(sk_sleep(sk), \u0026wait, TASK_INTERRUPTIBLE);\n1872:\t\t}\n1873:\t\n1874:\t\terr = sock_error(sk);\n1875:\t\tif (err \u0026\u0026\n1876:\t\t    sk-\u003esk_state != TCP_ESTABLISHED \u0026\u0026 sk-\u003esk_state != TCP_CLOSING) {\n1877:\t\t\tsk-\u003esk_state = TCP_CLOSE;\n1878:\t\t\tsock-\u003estate = SS_UNCONNECTED;\n1879:\t\t}\n1880:\t\n1881:\tout_wait:\n1882:\t\tfinish_wait(sk_sleep(sk), \u0026wait);\n1883:\tout:\n1884:\t\trelease_sock(sk);\n1885:\t\treturn err;\n1886:\t}\n1887:\t\n1888:\tstatic int vsock_accept(struct socket *sock, struct socket *newsock,\n1889:\t\t\t\tstruct proto_accept_arg *arg)\n1890:\t{\n1891:\t\tstruct sock *listener;\n1892:\t\tint err;\n1893:\t\tstruct sock *connected;\n1894:\t\tstruct vsock_sock *vconnected;\n1895:\t\tlong timeout;\n1896:\t\tDEFINE_WAIT(wait);\n1897:\t\n1898:\t\terr = 0;\n1899:\t\tlistener = sock-\u003esk;\n"
}

gemini-3.7-flash

null

null

							input: 5101
							output: 131
							thoughts: 698
						

**My Assessment of the vsock_connect Patch**

Okay, let's break this down. I'm looking at a patch that's modifying the `vsock_connect` function, specifically how it handles the socket state while waiting for the connection to be established. The core issue, as I understand it, is in line 1810 where the code waits for the socket state (`sk->sk_state`) to become `TCP_ESTABLISHED`. The original loop only checked for `TCP_ESTABLISHED`, but the remote end closing the connection during this wait could cause the state to transition to `TCP_CLOSING`. The previous logic had a potential flaw, allowing `TCP_CLOSING` states to be missed, resulting in an error check after the loop that could give an inaccurate error code.

The patch corrects this by explicitly checking for `TCP_CLOSING` within the loop condition, preventing the connection from stalling in the event of a remote closure during the connection attempt.

Now, the important question for me, given my expertise, is whether this introduces any uninitialized memory risks. Let's systematically go through the checks.

First, I'm checking if this patch affects any kernel structures that are sent to user space where uninitialized fields could be exposed. No. The patch only modifies internal socket state transitions, it doesn't touch any data transferred to user space.

Next, I'm verifying if there's any conditional logic or branching that relies on potentially uninitialized variables or struct fields. The patch manipulates the `sk->sk_state`, which is a well-defined field within the `struct sock` structure. So, no, there are no concerns about uninitialized memory being read.

Third, I'm evaluating whether the patch allocates or initializes any complex data structures in a way that could lead to later reads of uninitialized fields. There are no new allocations or data structures created or modified by this change.

Finally, I'm checking if it alters any bounds checks, lengths, or logic that would allow surrounding code to access uninitialized bytes of existing buffers. This patch doesn't involve any buffers or length calculations, so this isn't a concern either.

In short, this patch *only* modifies the socket state machine flow within `vsock_connect()`. It doesn't introduce any risk of uninitialized memory access. Any potential bugs related to state inconsistency, race conditions, or use-after-free issues would be detected by KASAN or standard testing/lockdep. Therefore, KMSAN is not required. The patch does not introduce any information leak risk.

**KMSANReasoning:** This patch modifies the state checking condition (`sk->sk_state == TCP_CLOSING`) within the connection loop and the error handling within `vsock_connect()`. It doesn't allocate any new memory, copy structures to user space, manipulate uninitialized buffers, or introduce any instances where uninitialized memory access could occur. Any issues with concurrency or socket state are either logical or related to object lifecycles, and these are handled by the standard detection mechanisms. Therefore, KMSAN is not applicable.
**NeedsKMSAN = false**

{
  "KMSANReasoning": "The patch modifies state machine handling in vsock_connect() by treating TCP_CLOSING similarly to TCP_ESTABLISHED when checking sk-\u003esk_state upon waking from connection wait and error handling. This change affects socket control flow and state transitions only. It does not introduce any new allocations, modify buffer copying or sizing, touch uninitialized memory, or expose kernel structures/padding to userspace. Therefore, there are no uninitialized memory read or info-leak risks that would necessitate a dedicated KMSAN fuzzing session.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch modifies state machine handling in vsock_connect() by treating TCP_CLOSING similarly to TCP_ESTABLISHED when checking sk-\u003esk_state upon waking from connection wait and error handling. This change affects socket control flow and state transitions only. It does not introduce any new allocations, modify buffer copying or sizing, touch uninitialized memory, or expose kernel structures/padding to userspace. Therefore, there are no uninitialized memory read or info-leak risks that would necessitate a dedicated KMSAN fuzzing session.",
  "NeedsKMSAN": false
}