AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/10/26 07:29	flow	patch-triage	4m Args: null Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD", "KVM_GUEST_MEMFD", "KVM_SW_PROTECTED_VM" ], "FocusSymbols": [ "kvm_gmem_link", "kvm_arch_gmem_link_allowed", "kvm_gmem_alloc_file", "kvm_gmem_create", "__kvm_gmem_create" ], "KMSANReasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl, enabling an existing guest_memfd file to be linked into a second VM by creating a new struct file sharing the underlying inode.\n\n1. No Info-leaks / User-space Copies: The ioctl takes an input struct kvm_link_guest_memfd copied from user space via copy_from_user() and only returns an integer file descriptor (or negative error code) via the ioctl return value. No kernel structures or data buffers are copied back to user space (no copy_to_user, put_user, or socket/netlink/bpf buffers), so there is no risk of uninitialized struct padding or data leaks.\n2. Initialization of Structs: The newly allocated struct gmem_file is allocated via kzalloc_obj(), which zero-initializes all bytes. Other local stack variables (such as struct timespec64 ts) are written before being read.\n3. Memory / Concurrency Bugs Caught by KASAN/LOCKDEP: Any potential risks introduced by this feature relate to reference counting (fops, inode, kvm instance, and struct file lifetimes), file descriptor management, or locking interactions (e.g., filemap_invalidate_lock), which are detected by KASAN, refcount tracking, and LOCKDEP rather than KMSAN.\n\nTherefore, this patch does not expose uninitialized memory risks, and a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false, "Reasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl and the KVM_CAP_GUEST_MEMFD_LINK capability, allowing guest_memfd instances to be linked across different VMs on the host. This refactors guest_memfd file allocation and introduces multi-VM sharing of underlying guest_memfd inodes, adding new concurrency, lifecycle, and memory invalidation interactions between VMs that are accessible from userspace via /dev/kvm.", "WorthFuzzing": true }
1/1	2026/10/26 07:29	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit a07cc8d33f8041de7abe39bc5a4e65d36a1c7e23\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Oct 26 07:29:57 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst\nindex 3d6a4bf01c700..bc54212e48c32 100644\n--- a/Documentation/virt/kvm/api.rst\n+++ b/Documentation/virt/kvm/api.rst\n@@ -6759,6 +6759,48 @@ if the guest_memfd memory was pinned in IOMMU page tables.\n \n See also: :ref:`KVM_SET_MEMORY_ATTRIBUTES`.\n \n+4.147 KVM_LINK_GUEST_MEMFD\n+--------------------------\n+\n+:Capability: KVM_CAP_GUEST_MEMFD_LINK\n+:Architectures: all\n+:Type: vm ioctl\n+:Parameters: struct kvm_link_guest_memfd (in)\n+:Returns: A file descriptor on success, \u003c0 on error\n+\n+Errors:\n+\n+ ========== ===============================================================\n+ EINVAL ``fd`` is not an open guest_memfd file descriptor, ``flags`` or\n+ ``reserved`` are not zero, the target VM is not compatible with\n+ the VM ``fd`` is associated with (e.g. on x86, the VMs are of\n+ different VM types), or ``fd`` is already associated with the\n+ target VM.\n+ EFAULT The parameter address was invalid.\n+ ENOMEM Ran out of memory.\n+ ========== ===============================================================\n+\n+::\n+\n+ struct kvm_link_guest_memfd {\n+\t__u64 fd;\n+\t__u64 flags;\n+\t__u64 reserved[6];\n+ };\n+\n+KVM_LINK_GUEST_MEMFD creates a new guest_memfd file descriptor that is\n+associated with the target VM (the VM on which the ioctl is invoked) and refers\n+to the same underlying memory as the existing guest_memfd referred to by ``fd``,\n+similar to how link() creates another name for an existing file. The new file\n+descriptor can be used in KVM_SET_USER_MEMORY_REGION2 for the target VM, and\n+the memory's contents, size, flags and (with in-place conversion) memory\n+attributes are shared by all linked guest_memfd instances.\n+\n+The primary use case is intra-host migration, where the destination VM needs to\n+access the same guest memory as the source VM without copying it.\n+\n+No flags are defined yet; ``flags`` and ``reserved`` must be zero.\n+\n .. _kvm_run:\n \n 5. The kvm_run structure\n@@ -9696,6 +9738,14 @@ take care to differentiate between these cases.\n The presence of this capability indicates that the nested KVM guest can\n start in ESA mode.\n \n+8.48 KVM_CAP_GUEST_MEMFD_LINK\n+-----------------------------\n+\n+:Architectures: all\n+\n+The presence of this capability indicates that KVM supports linking an\n+existing guest_memfd file to another VM via KVM_LINK_GUEST_MEMFD.\n+\n 9. Known KVM API problems\n =========================\n \ndiff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c\nindex c081e4b9b25de..4427d32290c0f 100644\n--- a/arch/x86/kvm/x86.c\n+++ b/arch/x86/kvm/x86.c\n@@ -10648,6 +10648,16 @@ bool kvm_arch_supports_gmem_init_shared(struct kvm kvm)\n \treturn gmem_in_place_conversion \|\| !kvm_arch_has_private_mem(kvm);\n }\n \n+bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src)\n+{\n+\t/\n+\t * Different VM types have different requirements for, and different\n+\t * (vendor) state associated with, guest_memfd memory, e.g. memory that\n+\t * is private to a TDX guest must never be mapped into a non-TDX VM.\n+\t /\n+\treturn dst-\u003earch.vm_type == src-\u003earch.vm_type;\n+}\n+\n #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT\n int kvm_arch_gmem_make_private(struct kvm kvm, gfn_t gfn, kvm_pfn_t pfn,\n \t\t\t kvm_pfn_t nr_pages)\ndiff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h\nindex 485f18454eb45..5cffb7ad376e1 100644\n--- a/include/linux/kvm_host.h\n+++ b/include/linux/kvm_host.h\n@@ -2585,6 +2585,7 @@ static inline bool kvm_is_private_gfn(struct kvm kvm, gfn_t gfn)\n #ifdef CONFIG_KVM_GUEST_MEMFD\n bool kvm_gmem_is_private_gfn(struct kvm kvm, gfn_t gfn);\n bool kvm_arch_supports_gmem_init_shared(struct kvm kvm);\n+bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src);\n \n static inline u64 kvm_gmem_get_supported_flags(struct kvm kvm)\n {\ndiff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h\nindex 8dff2fc1972e9..09926fa85fe6c 100644\n--- a/include/uapi/linux/kvm.h\n+++ b/include/uapi/linux/kvm.h\n@@ -1000,6 +1000,7 @@ struct kvm_enable_cap {\n #define KVM_CAP_PPC_COMPAT_CAPS 250\n #define KVM_CAP_ARM_PMU_V3_STRICT 251\n #define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 252\n+#define KVM_CAP_GUEST_MEMFD_LINK 253\n \n struct kvm_irq_routing_irqchip {\n \t__u32 irqchip;\n@@ -1690,4 +1691,12 @@ struct kvm_pre_fault_memory {\n \t__u64 padding[5];\n };\n \n+#define KVM_LINK_GUEST_MEMFD\t_IOWR(KVMIO, 0xd6, struct kvm_link_guest_memfd)\n+\n+struct kvm_link_guest_memfd {\n+\t__u64 fd;\n+\t__u64 flags;\n+\t__u64 reserved[6];\n+};\n+\n #endif /* __LINUX_KVM_H /\ndiff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm\nindex 239bc61ea384f..cffa0d165a945 100644\n--- a/tools/testing/selftests/kvm/Makefile.kvm\n+++ b/tools/testing/selftests/kvm/Makefile.kvm\n@@ -108,6 +108,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_counters_test\n TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test\n TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test\n TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test\n+TEST_GEN_PROGS_x86 += x86/private_mem_migrate_tests\n TEST_GEN_PROGS_x86 += x86/save_restore_pf_stress_test\n TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id\n TEST_GEN_PROGS_x86 += x86/set_sregs_test\ndiff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c\nindex 2233d871a38f4..ccde4d735c77c 100644\n--- a/tools/testing/selftests/kvm/guest_memfd_test.c\n+++ b/tools/testing/selftests/kvm/guest_memfd_test.c\n@@ -418,6 +418,68 @@ static void test_guest_memfd_flags(struct kvm_vm vm)\n \t}\n }\n \n+static void test_link(struct kvm_vm vm, int src_fd, size_t total_size)\n+{\n+\tstruct kvm_link_guest_memfd params = {};\n+\tstruct stat src_stat, dst_stat;\n+\tstruct kvm_vm dst_vm;\n+\tint dst_fd, bad_fd;\n+\tint ret;\n+\n+\t/* guest_memfd can only be linked between VMs of the same type. /\n+\tdst_vm = vm_create_barebones_type(vm-\u003etype);\n+\n+\t/ Linking with an fd that isn't open /\n+\tbad_fd = dup(src_fd);\n+\tTEST_ASSERT(bad_fd \u003e= 0, \"dup() failed\");\n+\tclose(bad_fd);\n+\tret = __vm_link_guest_memfd(dst_vm, bad_fd, 0);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\t/ Linking with an out-of-range fd, i.e. KVM must not truncate fd /\n+\tparams.fd = (1ULL \u003c\u003c 32) \| src_fd;\n+\tret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, \u0026params);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\t/ Linking with a non-gmem fd /\n+\tret = __vm_link_guest_memfd(dst_vm, dst_vm-\u003efd, 0);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\t/ Linking with invalid flags /\n+\tret = __vm_link_guest_memfd(dst_vm, src_fd, 1);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\t/ Linking with non-zero reserved fields /\n+\tparams.fd = src_fd;\n+\tparams.reserved[5] = 1;\n+\tret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, \u0026params);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\t/ Linking with an already-associated vm /\n+\tret = __vm_link_guest_memfd(vm, src_fd, 0);\n+\tTEST_ASSERT_EQ(ret, -1);\n+\tTEST_ASSERT_EQ(errno, EINVAL);\n+\n+\tdst_fd = __vm_link_guest_memfd(dst_vm, src_fd, 0);\n+\tTEST_ASSERT(dst_fd \u003e= 0, \"linking should succeed with valid inputs\");\n+\tTEST_ASSERT(src_fd != dst_fd, \"linking should return a different fd\");\n+\n+\tret = fstat(src_fd, \u0026src_stat);\n+\tTEST_ASSERT_EQ(ret, 0);\n+\tret = fstat(dst_fd, \u0026dst_stat);\n+\tTEST_ASSERT_EQ(ret, 0);\n+\tTEST_ASSERT(src_stat.st_ino == dst_stat.st_ino,\n+\t\t \"src and dst files should have the same inode number\");\n+\n+\tclose(dst_fd);\n+\tkvm_vm_free(dst_vm);\n+}\n+\n #define ____gmem_test(__test, __vm, __flags, __gmem_size, args...)\t\\\n do {\t\t\t\t\t\t\t\t\t\\\n \tint fd = vm_create_guest_memfd(__vm, __gmem_size, __flags);\t\\\n@@ -467,6 +529,8 @@ static void __test_guest_memfd(struct kvm_vm vm, u64 flags)\n \tgmem_test(fallocate, vm, flags);\n \tgmem_test(invalid_punch_hole, vm, flags);\n \tgmem_test_vm(invalid_binding, vm, flags);\n+\tif (kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK))\n+\t\tgmem_test_vm(link, vm, flags);\n }\n \n static void test_guest_memfd(unsigned long vm_type)\ndiff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h\nindex 777fa3dbf88d6..f8eca3f7993d0 100644\n--- a/tools/testing/selftests/kvm/include/kvm_util.h\n+++ b/tools/testing/selftests/kvm/include/kvm_util.h\n@@ -787,6 +787,24 @@ static inline int vm_create_guest_memfd(struct kvm_vm vm, u64 size,\n \treturn fd;\n }\n \n+static inline int __vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags)\n+{\n+\tstruct kvm_link_guest_memfd params = {\n+\t\t.fd = fd,\n+\t\t.flags = flags,\n+\t};\n+\n+\treturn __vm_ioctl(vm, KVM_LINK_GUEST_MEMFD, \u0026params);\n+}\n+\n+static inline int vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags)\n+{\n+\tint new_fd = __vm_link_guest_memfd(vm, fd, flags);\n+\n+\tTEST_ASSERT(new_fd \u003e= 0, KVM_IOCTL_ERROR(KVM_LINK_GUEST_MEMFD, new_fd));\n+\treturn new_fd;\n+}\n+\n void vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags,\n \t\t\t gpa_t gpa, u64 size, void hva);\n int __vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags,\ndiff --git a/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c\nnew file mode 100644\nindex 0000000000000..17bebf850b4c4\n--- /dev/null\n+++ b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c\n@@ -0,0 +1,118 @@\n+// SPDX-License-Identifier: GPL-2.0\n+#include \"kvm_util.h\"\n+#include \"test_util.h\"\n+#include \"ucall_common.h\"\n+#include \u003clinux/kvm.h\u003e\n+#include \u003clinux/sizes.h\u003e\n+\n+#define TRANSFER_PRIVATE_MEM_TEST_SLOT 10\n+#define TRANSFER_PRIVATE_MEM_GPA ((uint64_t)(1ull \u003c\u003c 32))\n+#define TRANSFER_PRIVATE_MEM_GVA TRANSFER_PRIVATE_MEM_GPA\n+#define TRANSFER_PRIVATE_MEM_VALUE 0xdeadbeef\n+\n+static const struct vm_shape protected_shape = {\n+\t.mode = VM_MODE_DEFAULT,\n+\t.type = KVM_X86_SW_PROTECTED_VM,\n+};\n+\n+static void transfer_private_mem_guest_code_src(void)\n+{\n+\tuint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA;\n+\n+\tWRITE_ONCE(ptr, TRANSFER_PRIVATE_MEM_VALUE);\n+\n+\tGUEST_SYNC1(READ_ONCE(ptr));\n+}\n+\n+static void transfer_private_mem_guest_code_dst(void)\n+{\n+\tuint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA;\n+\n+\tGUEST_SYNC1(READ_ONCE(ptr));\n+}\n+\n+static void add_private_mem(struct kvm_vm vm, int memfd)\n+{\n+\tvm_mem_add(vm, DEFAULT_VM_MEM_SRC, TRANSFER_PRIVATE_MEM_GPA,\n+\t\t TRANSFER_PRIVATE_MEM_TEST_SLOT, 1, KVM_MEM_GUEST_MEMFD,\n+\t\t memfd, 0, 0);\n+\n+\tvirt_map(vm, TRANSFER_PRIVATE_MEM_GVA, TRANSFER_PRIVATE_MEM_GPA, 1);\n+\n+\t/\n+\t guest_memfd memory is private by default if guest_memfd tracks\n+\t * memory attributes, otherwise it must be converted via the VM.\n+\t /\n+\tif (!kvm_has_gmem_attributes)\n+\t\tvm_mem_set_private(vm, TRANSFER_PRIVATE_MEM_GPA, SZ_4K);\n+}\n+\n+static void test_transfer_private_mem(void)\n+{\n+\tstruct kvm_vm src_vm, dst_vm;\n+\tstruct kvm_vcpu src_vcpu, dst_vcpu;\n+\tint src_memfd, dst_memfd;\n+\tstruct ucall uc;\n+\n+\t/ Build the source VM, use it to write to private memory /\n+\tsrc_vm = __vm_create_shape_with_one_vcpu(protected_shape, \u0026src_vcpu, 0,\n+\t\t\t\t\t\t transfer_private_mem_guest_code_src);\n+\tsrc_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0);\n+\n+\tadd_private_mem(src_vm, src_memfd);\n+\n+\tvcpu_run(src_vcpu);\n+\tTEST_ASSERT_KVM_EXIT_REASON(src_vcpu, KVM_EXIT_IO);\n+\tget_ucall(src_vcpu, \u0026uc);\n+\tTEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE,\n+\t\t \"Source VM should be able to write to private memory\");\n+\n+\t/ Build the destination VM with linked fd /\n+\tdst_vm = __vm_create_shape_with_one_vcpu(protected_shape, \u0026dst_vcpu, 0,\n+\t\t\t\t\t\t transfer_private_mem_guest_code_dst);\n+\tdst_memfd = vm_link_guest_memfd(dst_vm, src_memfd, 0);\n+\n+\tadd_private_mem(dst_vm, dst_memfd);\n+\n+\tvcpu_run(dst_vcpu);\n+\tTEST_ASSERT_KVM_EXIT_REASON(dst_vcpu, KVM_EXIT_IO);\n+\tget_ucall(dst_vcpu, \u0026uc);\n+\tTEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE,\n+\t\t \"Destination VM should be able to read value transferred\");\n+\n+\tclose(dst_memfd);\n+\tclose(src_memfd);\n+\tkvm_vm_free(dst_vm);\n+\tkvm_vm_free(src_vm);\n+}\n+\n+static void test_link_different_vm_type(void)\n+{\n+\tstruct kvm_vm src_vm, dst_vm;\n+\tint src_memfd, ret;\n+\n+\tsrc_vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM);\n+\tsrc_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0);\n+\n+\tdst_vm = vm_create_barebones_type(KVM_X86_DEFAULT_VM);\n+\n+\tret = __vm_link_guest_memfd(dst_vm, src_memfd, 0);\n+\tTEST_ASSERT(ret == -1 \u0026\u0026 errno == EINVAL,\n+\t\t \"Linking into a VM of a different type should fail, ret: %d, errno: %d\",\n+\t\t ret, errno);\n+\n+\tclose(src_memfd);\n+\tkvm_vm_free(dst_vm);\n+\tkvm_vm_free(src_vm);\n+}\n+\n+int main(int argc, char argv[])\n+{\n+\tTEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) \u0026 BIT(KVM_X86_SW_PROTECTED_VM));\n+\tTEST_REQUIRE(kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK));\n+\n+\ttest_transfer_private_mem();\n+\ttest_link_different_vm_type();\n+\n+\treturn 0;\n+}\ndiff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c\nindex 93f3d29d5751a..54b11747a8c48 100644\n--- a/virt/kvm/guest_memfd.c\n+++ b/virt/kvm/guest_memfd.c\n@@ -892,6 +892,15 @@ bool __weak kvm_arch_supports_gmem_init_shared(struct kvm kvm)\n \treturn true;\n }\n \n+/\n+ * Returns true if a guest_memfd instance associated with @src may be linked\n+ * into @dst, i.e. if both VMs can safely share the underlying memory.\n+ /\n+bool __weak kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src)\n+{\n+\treturn kvm_arch_has_private_mem(dst) == kvm_arch_has_private_mem(src);\n+}\n+\n static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags)\n {\n \tstruct gmem_inode gi = GMEM_I(inode);\n@@ -937,10 +946,50 @@ static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags)\n \treturn r;\n }\n \n+/\n+ Allocate a new guest_memfd file for @kvm that refers to @inode. On success,\n+ * the returned file takes over the caller's reference to @inode.\n+ /\n+static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode,\n+\t\t\t\t\tconst char name)\n+{\n+\tstruct gmem_file f;\n+\tstruct file file;\n+\n+\tf = kzalloc_obj(f);\n+\tif (!f)\n+\t\treturn ERR_PTR(-ENOMEM);\n+\n+\t/* __fput() will take care of fops_put(). /\n+\tif (!fops_get(\u0026kvm_gmem_fops)) {\n+\t\tkfree(f);\n+\t\treturn ERR_PTR(-ENOENT);\n+\t}\n+\n+\tfile = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, \u0026kvm_gmem_fops);\n+\tif (IS_ERR(file)) {\n+\t\tfops_put(\u0026kvm_gmem_fops);\n+\t\tkfree(f);\n+\t\treturn file;\n+\t}\n+\n+\tfile-\u003ef_flags \|= O_LARGEFILE;\n+\tfile-\u003eprivate_data = f;\n+\n+\tkvm_get_kvm(kvm);\n+\tf-\u003ekvm = kvm;\n+\txa_init(\u0026f-\u003ebindings);\n+\n+\tfilemap_invalidate_lock(inode-\u003ei_mapping);\n+\tlist_add(\u0026f-\u003eentry, \u0026GMEM_I(inode)-\u003egmem_file_list);\n+\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n+\n+\treturn file;\n+}\n+\n static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags)\n {\n \tstatic const char name = \"[kvm-gmem]\";\n-\tstruct gmem_file f;\n \tstruct inode inode;\n \tstruct file file;\n \tint fd, err;\n@@ -949,51 +998,27 @@ static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags)\n \tif (fd \u003c 0)\n \t\treturn fd;\n \n-\tf = kzalloc_obj(f);\n-\tif (!f) {\n-\t\terr = -ENOMEM;\n-\t\tgoto err_fd;\n-\t}\n-\n-\t/* __fput() will take care of fops_put(). /\n-\tif (!fops_get(\u0026kvm_gmem_fops)) {\n-\t\terr = -ENOENT;\n-\t\tgoto err_gmem;\n-\t}\n-\n \tinode = anon_inode_make_secure_inode(kvm_gmem_mnt-\u003emnt_sb, name, NULL);\n \tif (IS_ERR(inode)) {\n \t\terr = PTR_ERR(inode);\n-\t\tgoto err_fops;\n+\t\tgoto err_fd;\n \t}\n \n \terr = kvm_gmem_init_inode(inode, size, flags);\n \tif (err)\n \t\tgoto err_inode;\n \n-\tfile = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, \u0026kvm_gmem_fops);\n+\tfile = kvm_gmem_alloc_file(kvm, inode, name);\n \tif (IS_ERR(file)) {\n \t\terr = PTR_ERR(file);\n \t\tgoto err_inode;\n \t}\n \n-\tfile-\u003ef_flags \|= O_LARGEFILE;\n-\tfile-\u003eprivate_data = f;\n-\n-\tkvm_get_kvm(kvm);\n-\tf-\u003ekvm = kvm;\n-\txa_init(\u0026f-\u003ebindings);\n-\tlist_add(\u0026f-\u003eentry, \u0026GMEM_I(inode)-\u003egmem_file_list);\n-\n \tfd_install(fd, file);\n \treturn fd;\n \n err_inode:\n \tiput(inode);\n-err_fops:\n-\tfops_put(\u0026kvm_gmem_fops);\n-err_gmem:\n-\tkfree(f);\n err_fd:\n \tput_unused_fd(fd);\n \treturn err;\n@@ -1013,6 +1038,77 @@ int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args)\n \treturn __kvm_gmem_create(kvm, size, flags);\n }\n \n+int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args)\n+{\n+\tstatic const char name = \"[kvm-gmem]\";\n+\tu64 flags = args-\u003eflags;\n+\tu64 valid_flags = 0;\n+\tstruct file dst_file, src_file;\n+\tstruct gmem_file gmem;\n+\tstruct timespec64 ts;\n+\tstruct inode inode;\n+\tstruct fd f;\n+\tint ret, fd, i;\n+\n+\tif (flags \u0026 ~valid_flags)\n+\t\treturn -EINVAL;\n+\n+\tfor (i = 0; i \u003c ARRAY_SIZE(args-\u003ereserved); i++) {\n+\t\tif (args-\u003ereserved[i])\n+\t\t\treturn -EINVAL;\n+\t}\n+\n+\t/* Don't let fdget() silently truncate the fd. /\n+\tif (args-\u003efd \u003e INT_MAX)\n+\t\treturn -EINVAL;\n+\n+\tf = fdget(args-\u003efd);\n+\tsrc_file = fd_file(f);\n+\tif (!src_file)\n+\t\treturn -EINVAL;\n+\n+\tret = -EINVAL;\n+\tif (src_file-\u003ef_op != \u0026kvm_gmem_fops)\n+\t\tgoto out;\n+\n+\t/ Cannot link a gmem file with the same VM again. /\n+\tgmem = src_file-\u003eprivate_data;\n+\tif (gmem-\u003ekvm == kvm)\n+\t\tgoto out;\n+\n+\tif (!kvm_arch_gmem_link_allowed(kvm, gmem-\u003ekvm))\n+\t\tgoto out;\n+\n+\tfd = get_unused_fd_flags(0);\n+\tif (fd \u003c 0) {\n+\t\tret = fd;\n+\t\tgoto out;\n+\t}\n+\n+\tinode = file_inode(src_file);\n+\tihold(inode);\n+\n+\tdst_file = kvm_gmem_alloc_file(kvm, inode, name);\n+\tif (IS_ERR(dst_file)) {\n+\t\tiput(inode);\n+\t\tret = PTR_ERR(dst_file);\n+\t\tgoto out_fd;\n+\t}\n+\n+\tts = inode_set_ctime_current(inode);\n+\tinode_set_atime_to_ts(inode, ts);\n+\n+\tfd_install(fd, dst_file);\n+\tfdput(f);\n+\treturn fd;\n+\n+out_fd:\n+\tput_unused_fd(fd);\n+out:\n+\tfdput(f);\n+\treturn ret;\n+}\n+\n int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot,\n \t\t\t\t unsigned int fd, uoff_t offset)\n {\ndiff --git a/virt/kvm/guest_memfd.h b/virt/kvm/guest_memfd.h\nindex 01bd359d27e30..7ffa4fa7337e9 100644\n--- a/virt/kvm/guest_memfd.h\n+++ b/virt/kvm/guest_memfd.h\n@@ -8,6 +8,7 @@\n int kvm_gmem_init(struct module module);\n void kvm_gmem_exit(void);\n int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args);\n+int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args);\n int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot,\n \t\t\t\t unsigned int fd, uoff_t offset);\n int kvm_gmem_commit_memory_region(struct kvm kvm, struct kvm_memory_slot slot);\ndiff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c\nindex 3ed481c4a15b6..135e7bb7609a8 100644\n--- a/virt/kvm/kvm_main.c\n+++ b/virt/kvm/kvm_main.c\n@@ -5008,6 +5008,8 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm kvm, long arg)\n \t\t\treturn 0;\n \n \t\treturn KVM_MEMORY_ATTRIBUTE_PRIVATE;\n+\tcase KVM_CAP_GUEST_MEMFD_LINK:\n+\t\treturn 1;\n #endif\n \tdefault:\n \t\tbreak;\n@@ -5453,6 +5455,16 @@ static long kvm_vm_ioctl(struct file filp,\n \t\tr = kvm_gmem_create(kvm, \u0026guest_memfd);\n \t\tbreak;\n \t}\n+\tcase KVM_LINK_GUEST_MEMFD: {\n+\t\tstruct kvm_link_guest_memfd params;\n+\n+\t\tr = -EFAULT;\n+\t\tif (copy_from_user(\u0026params, argp, sizeof(params)))\n+\t\t\tgoto out;\n+\n+\t\tr = kvm_gmem_link(kvm, \u0026params);\n+\t\tbreak;\n+\t}\n #endif\n \tdefault:\n \t\tr = kvm_arch_vm_ioctl(filp, ioctl, arg);\n" }
2/1	2026/10/26 07:29	agent	patch-evaluator	2m Model: core Args: null Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD", "KVM_GUEST_MEMFD", "KVM_SW_PROTECTED_VM" ], "FocusSymbols": [ "kvm_gmem_link", "kvm_arch_gmem_link_allowed", "kvm_gmem_alloc_file", "kvm_gmem_create", "__kvm_gmem_create" ], "Reasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl and the KVM_CAP_GUEST_MEMFD_LINK capability, allowing guest_memfd instances to be linked across different VMs on the host. This refactors guest_memfd file allocation and introduces multi-VM sharing of underlying guest_memfd inodes, adding new concurrency, lifecycle, and memory invalidation interactions between VMs that are accessible from userspace via /dev/kvm.", "WorthFuzzing": true } Instruction: 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. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit a07cc8d33f8041de7abe39bc5a4e65d36a1c7e23 Author: syz-cluster <triage@syzkaller.com> Date: Mon Oct 26 07:29:57 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 3d6a4bf01c700..bc54212e48c32 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6759,6 +6759,48 @@ if the guest_memfd memory was pinned in IOMMU page tables. See also: :ref:`KVM_SET_MEMORY_ATTRIBUTES`. +4.147 KVM_LINK_GUEST_MEMFD +-------------------------- + +:Capability: KVM_CAP_GUEST_MEMFD_LINK +:Architectures: all +:Type: vm ioctl +:Parameters: struct kvm_link_guest_memfd (in) +:Returns: A file descriptor on success, <0 on error + +Errors: + + ========== =============================================================== + EINVAL ``fd`` is not an open guest_memfd file descriptor, ``flags`` or + ``reserved`` are not zero, the target VM is not compatible with + the VM ``fd`` is associated with (e.g. on x86, the VMs are of + different VM types), or ``fd`` is already associated with the + target VM. + EFAULT The parameter address was invalid. + ENOMEM Ran out of memory. + ========== =============================================================== + +:: + + struct kvm_link_guest_memfd { + __u64 fd; + __u64 flags; + __u64 reserved[6]; + }; + +KVM_LINK_GUEST_MEMFD creates a new guest_memfd file descriptor that is +associated with the target VM (the VM on which the ioctl is invoked) and refers +to the same underlying memory as the existing guest_memfd referred to by ``fd``, +similar to how link() creates another name for an existing file. The new file +descriptor can be used in KVM_SET_USER_MEMORY_REGION2 for the target VM, and +the memory's contents, size, flags and (with in-place conversion) memory +attributes are shared by all linked guest_memfd instances. + +The primary use case is intra-host migration, where the destination VM needs to +access the same guest memory as the source VM without copying it. + +No flags are defined yet; ``flags`` and ``reserved`` must be zero. + .. _kvm_run: 5. The kvm_run structure @@ -9696,6 +9738,14 @@ take care to differentiate between these cases. The presence of this capability indicates that the nested KVM guest can start in ESA mode. +8.48 KVM_CAP_GUEST_MEMFD_LINK +----------------------------- + +:Architectures: all + +The presence of this capability indicates that KVM supports linking an +existing guest_memfd file to another VM via KVM_LINK_GUEST_MEMFD. + 9. Known KVM API problems ========================= diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c081e4b9b25de..4427d32290c0f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10648,6 +10648,16 @@ bool kvm_arch_supports_gmem_init_shared(struct kvm kvm) return gmem_in_place_conversion \|\| !kvm_arch_has_private_mem(kvm); } +bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src) +{ + / + * Different VM types have different requirements for, and different + * (vendor) state associated with, guest_memfd memory, e.g. memory that + * is private to a TDX guest must never be mapped into a non-TDX VM. + / + return dst->arch.vm_type == src->arch.vm_type; +} + #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT int kvm_arch_gmem_make_private(struct kvm kvm, gfn_t gfn, kvm_pfn_t pfn, kvm_pfn_t nr_pages) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 485f18454eb45..5cffb7ad376e1 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2585,6 +2585,7 @@ static inline bool kvm_is_private_gfn(struct kvm kvm, gfn_t gfn) #ifdef CONFIG_KVM_GUEST_MEMFD bool kvm_gmem_is_private_gfn(struct kvm kvm, gfn_t gfn); bool kvm_arch_supports_gmem_init_shared(struct kvm kvm); +bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src); static inline u64 kvm_gmem_get_supported_flags(struct kvm kvm) { diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8dff2fc1972e9..09926fa85fe6c 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1000,6 +1000,7 @@ struct kvm_enable_cap { #define KVM_CAP_PPC_COMPAT_CAPS 250 #define KVM_CAP_ARM_PMU_V3_STRICT 251 #define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 252 +#define KVM_CAP_GUEST_MEMFD_LINK 253 struct kvm_irq_routing_irqchip { __u32 irqchip; @@ -1690,4 +1691,12 @@ struct kvm_pre_fault_memory { __u64 padding[5]; }; +#define KVM_LINK_GUEST_MEMFD _IOWR(KVMIO, 0xd6, struct kvm_link_guest_memfd) + +struct kvm_link_guest_memfd { + __u64 fd; + __u64 flags; + __u64 reserved[6]; +}; + #endif /* __LINUX_KVM_H / diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm index 239bc61ea384f..cffa0d165a945 100644 --- a/tools/testing/selftests/kvm/Makefile.kvm +++ b/tools/testing/selftests/kvm/Makefile.kvm @@ -108,6 +108,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_counters_test TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test +TEST_GEN_PROGS_x86 += x86/private_mem_migrate_tests TEST_GEN_PROGS_x86 += x86/save_restore_pf_stress_test TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id TEST_GEN_PROGS_x86 += x86/set_sregs_test diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c index 2233d871a38f4..ccde4d735c77c 100644 --- a/tools/testing/selftests/kvm/guest_memfd_test.c +++ b/tools/testing/selftests/kvm/guest_memfd_test.c @@ -418,6 +418,68 @@ static void test_guest_memfd_flags(struct kvm_vm vm) } } +static void test_link(struct kvm_vm vm, int src_fd, size_t total_size) +{ + struct kvm_link_guest_memfd params = {}; + struct stat src_stat, dst_stat; + struct kvm_vm dst_vm; + int dst_fd, bad_fd; + int ret; + + /* guest_memfd can only be linked between VMs of the same type. / + dst_vm = vm_create_barebones_type(vm->type); + + / Linking with an fd that isn't open / + bad_fd = dup(src_fd); + TEST_ASSERT(bad_fd >= 0, "dup() failed"); + close(bad_fd); + ret = __vm_link_guest_memfd(dst_vm, bad_fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with an out-of-range fd, i.e. KVM must not truncate fd / + params.fd = (1ULL << 32) \| src_fd; + ret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, &params); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with a non-gmem fd / + ret = __vm_link_guest_memfd(dst_vm, dst_vm->fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with invalid flags / + ret = __vm_link_guest_memfd(dst_vm, src_fd, 1); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with non-zero reserved fields / + params.fd = src_fd; + params.reserved[5] = 1; + ret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, &params); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with an already-associated vm / + ret = __vm_link_guest_memfd(vm, src_fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + dst_fd = __vm_link_guest_memfd(dst_vm, src_fd, 0); + TEST_ASSERT(dst_fd >= 0, "linking should succeed with valid inputs"); + TEST_ASSERT(src_fd != dst_fd, "linking should return a different fd"); + + ret = fstat(src_fd, &src_stat); + TEST_ASSERT_EQ(ret, 0); + ret = fstat(dst_fd, &dst_stat); + TEST_ASSERT_EQ(ret, 0); + TEST_ASSERT(src_stat.st_ino == dst_stat.st_ino, + "src and dst files should have the same inode number"); + + close(dst_fd); + kvm_vm_free(dst_vm); +} + #define ____gmem_test(__test, __vm, __flags, __gmem_size, args...) \ do { \ int fd = vm_create_guest_memfd(__vm, __gmem_size, __flags); \ @@ -467,6 +529,8 @@ static void __test_guest_memfd(struct kvm_vm vm, u64 flags) gmem_test(fallocate, vm, flags); gmem_test(invalid_punch_hole, vm, flags); gmem_test_vm(invalid_binding, vm, flags); + if (kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK)) + gmem_test_vm(link, vm, flags); } static void test_guest_memfd(unsigned long vm_type) diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h index 777fa3dbf88d6..f8eca3f7993d0 100644 --- a/tools/testing/selftests/kvm/include/kvm_util.h +++ b/tools/testing/selftests/kvm/include/kvm_util.h @@ -787,6 +787,24 @@ static inline int vm_create_guest_memfd(struct kvm_vm vm, u64 size, return fd; } +static inline int __vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags) +{ + struct kvm_link_guest_memfd params = { + .fd = fd, + .flags = flags, + }; + + return __vm_ioctl(vm, KVM_LINK_GUEST_MEMFD, &params); +} + +static inline int vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags) +{ + int new_fd = __vm_link_guest_memfd(vm, fd, flags); + + TEST_ASSERT(new_fd >= 0, KVM_IOCTL_ERROR(KVM_LINK_GUEST_MEMFD, new_fd)); + return new_fd; +} + void vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags, gpa_t gpa, u64 size, void hva); int __vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags, diff --git a/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c new file mode 100644 index 0000000000000..17bebf850b4c4 --- /dev/null +++ b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c @@ -0,0 +1,118 @@ +// SPDX-License-Identifier: GPL-2.0 +#include "kvm_util.h" +#include "test_util.h" +#include "ucall_common.h" +#include <linux/kvm.h> +#include <linux/sizes.h> + +#define TRANSFER_PRIVATE_MEM_TEST_SLOT 10 +#define TRANSFER_PRIVATE_MEM_GPA ((uint64_t)(1ull << 32)) +#define TRANSFER_PRIVATE_MEM_GVA TRANSFER_PRIVATE_MEM_GPA +#define TRANSFER_PRIVATE_MEM_VALUE 0xdeadbeef + +static const struct vm_shape protected_shape = { + .mode = VM_MODE_DEFAULT, + .type = KVM_X86_SW_PROTECTED_VM, +}; + +static void transfer_private_mem_guest_code_src(void) +{ + uint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA; + + WRITE_ONCE(ptr, TRANSFER_PRIVATE_MEM_VALUE); + + GUEST_SYNC1(READ_ONCE(ptr)); +} + +static void transfer_private_mem_guest_code_dst(void) +{ + uint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA; + + GUEST_SYNC1(READ_ONCE(ptr)); +} + +static void add_private_mem(struct kvm_vm vm, int memfd) +{ + vm_mem_add(vm, DEFAULT_VM_MEM_SRC, TRANSFER_PRIVATE_MEM_GPA, + TRANSFER_PRIVATE_MEM_TEST_SLOT, 1, KVM_MEM_GUEST_MEMFD, + memfd, 0, 0); + + virt_map(vm, TRANSFER_PRIVATE_MEM_GVA, TRANSFER_PRIVATE_MEM_GPA, 1); + + /* + * guest_memfd memory is private by default if guest_memfd tracks + * memory attributes, otherwise it must be converted via the VM. + / + if (!kvm_has_gmem_attributes) + vm_mem_set_private(vm, TRANSFER_PRIVATE_MEM_GPA, SZ_4K); +} + +static void test_transfer_private_mem(void) +{ + struct kvm_vm src_vm, dst_vm; + struct kvm_vcpu src_vcpu, dst_vcpu; + int src_memfd, dst_memfd; + struct ucall uc; + + / Build the source VM, use it to write to private memory / + src_vm = __vm_create_shape_with_one_vcpu(protected_shape, &src_vcpu, 0, + transfer_private_mem_guest_code_src); + src_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0); + + add_private_mem(src_vm, src_memfd); + + vcpu_run(src_vcpu); + TEST_ASSERT_KVM_EXIT_REASON(src_vcpu, KVM_EXIT_IO); + get_ucall(src_vcpu, &uc); + TEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE, + "Source VM should be able to write to private memory"); + + / Build the destination VM with linked fd / + dst_vm = __vm_create_shape_with_one_vcpu(protected_shape, &dst_vcpu, 0, + transfer_private_mem_guest_code_dst); + dst_memfd = vm_link_guest_memfd(dst_vm, src_memfd, 0); + + add_private_mem(dst_vm, dst_memfd); + + vcpu_run(dst_vcpu); + TEST_ASSERT_KVM_EXIT_REASON(dst_vcpu, KVM_EXIT_IO); + get_ucall(dst_vcpu, &uc); + TEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE, + "Destination VM should be able to read value transferred"); + + close(dst_memfd); + close(src_memfd); + kvm_vm_free(dst_vm); + kvm_vm_free(src_vm); +} + +static void test_link_different_vm_type(void) +{ + struct kvm_vm src_vm, dst_vm; + int src_memfd, ret; + + src_vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM); + src_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0); + + dst_vm = vm_create_barebones_type(KVM_X86_DEFAULT_VM); + + ret = __vm_link_guest_memfd(dst_vm, src_memfd, 0); + TEST_ASSERT(ret == -1 && errno == EINVAL, + "Linking into a VM of a different type should fail, ret: %d, errno: %d", + ret, errno); + + close(src_memfd); + kvm_vm_free(dst_vm); + kvm_vm_free(src_vm); +} + +int main(int argc, char argv[]) +{ + TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM)); + TEST_REQUIRE(kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK)); + + test_transfer_private_mem(); + test_link_different_vm_type(); + + return 0; +} diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 93f3d29d5751a..54b11747a8c48 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -892,6 +892,15 @@ bool __weak kvm_arch_supports_gmem_init_shared(struct kvm kvm) return true; } +/ + * Returns true if a guest_memfd instance associated with @src may be linked + * into @dst, i.e. if both VMs can safely share the underlying memory. + / +bool __weak kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src) +{ + return kvm_arch_has_private_mem(dst) == kvm_arch_has_private_mem(src); +} + static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags) { struct gmem_inode gi = GMEM_I(inode); @@ -937,10 +946,50 @@ static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags) return r; } +/* + * Allocate a new guest_memfd file for @kvm that refers to @inode. On success, + * the returned file takes over the caller's reference to @inode. + / +static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode, + const char name) +{ + struct gmem_file f; + struct file file; + + f = kzalloc_obj(f); + if (!f) + return ERR_PTR(-ENOMEM); + + /* __fput() will take care of fops_put(). / + if (!fops_get(&kvm_gmem_fops)) { + kfree(f); + return ERR_PTR(-ENOENT); + } + + file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops); + if (IS_ERR(file)) { + fops_put(&kvm_gmem_fops); + kfree(f); + return file; + } + + file->f_flags \|= O_LARGEFILE; + file->private_data = f; + + kvm_get_kvm(kvm); + f->kvm = kvm; + xa_init(&f->bindings); + + filemap_invalidate_lock(inode->i_mapping); + list_add(&f->entry, &GMEM_I(inode)->gmem_file_list); + filemap_invalidate_unlock(inode->i_mapping); + + return file; +} + static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags) { static const char name = "[kvm-gmem]"; - struct gmem_file f; struct inode inode; struct file file; int fd, err; @@ -949,51 +998,27 @@ static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags) if (fd < 0) return fd; - f = kzalloc_obj(f); - if (!f) { - err = -ENOMEM; - goto err_fd; - } - - /* __fput() will take care of fops_put(). / - if (!fops_get(&kvm_gmem_fops)) { - err = -ENOENT; - goto err_gmem; - } - inode = anon_inode_make_secure_inode(kvm_gmem_mnt->mnt_sb, name, NULL); if (IS_ERR(inode)) { err = PTR_ERR(inode); - goto err_fops; + goto err_fd; } err = kvm_gmem_init_inode(inode, size, flags); if (err) goto err_inode; - file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops); + file = kvm_gmem_alloc_file(kvm, inode, name); if (IS_ERR(file)) { err = PTR_ERR(file); goto err_inode; } - file->f_flags \|= O_LARGEFILE; - file->private_data = f; - - kvm_get_kvm(kvm); - f->kvm = kvm; - xa_init(&f->bindings); - list_add(&f->entry, &GMEM_I(inode)->gmem_file_list); - fd_install(fd, file); return fd; err_inode: iput(inode); -err_fops: - fops_put(&kvm_gmem_fops); -err_gmem: - kfree(f); err_fd: put_unused_fd(fd); return err; @@ -1013,6 +1038,77 @@ int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args) return __kvm_gmem_create(kvm, size, flags); } +int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args) +{ + static const char name = "[kvm-gmem]"; + u64 flags = args->flags; + u64 valid_flags = 0; + struct file dst_file, src_file; + struct gmem_file gmem; + struct timespec64 ts; + struct inode inode; + struct fd f; + int ret, fd, i; + + if (flags & ~valid_flags) + return -EINVAL; + + for (i = 0; i < ARRAY_SIZE(args->reserved); i++) { + if (args->reserved[i]) + return -EINVAL; + } + + /* Don't let fdget() silently truncate the fd. / + if (args->fd > INT_MAX) + return -EINVAL; + + f = fdget(args->fd); + src_file = fd_file(f); + if (!src_file) + return -EINVAL; + + ret = -EINVAL; + if (src_file->f_op != &kvm_gmem_fops) + goto out; + + / Cannot link a gmem file with the same VM again. / + gmem = src_file->private_data; + if (gmem->kvm == kvm) + goto out; + + if (!kvm_arch_gmem_link_allowed(kvm, gmem->kvm)) + goto out; + + fd = get_unused_fd_flags(0); + if (fd < 0) { + ret = fd; + goto out; + } + + inode = file_inode(src_file); + ihold(inode); + + dst_file = kvm_gmem_alloc_file(kvm, inode, name); + if (IS_ERR(dst_file)) { + iput(inode); + ret = PTR_ERR(dst_file); + goto out_fd; + } + + ts = inode_set_ctime_current(inode); + inode_set_atime_to_ts(inode, ts); + + fd_install(fd, dst_file); + fdput(f); + return fd; + +out_fd: + put_unused_fd(fd); +out: + fdput(f); + return ret; +} + int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot, unsigned int fd, uoff_t offset) { diff --git a/virt/kvm/guest_memfd.h b/virt/kvm/guest_memfd.h index 01bd359d27e30..7ffa4fa7337e9 100644 --- a/virt/kvm/guest_memfd.h +++ b/virt/kvm/guest_memfd.h @@ -8,6 +8,7 @@ int kvm_gmem_init(struct module module); void kvm_gmem_exit(void); int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args); +int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args); int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot, unsigned int fd, uoff_t offset); int kvm_gmem_commit_memory_region(struct kvm kvm, struct kvm_memory_slot slot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 3ed481c4a15b6..135e7bb7609a8 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5008,6 +5008,8 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm kvm, long arg) return 0; return KVM_MEMORY_ATTRIBUTE_PRIVATE; + case KVM_CAP_GUEST_MEMFD_LINK: + return 1; #endif default: break; @@ -5453,6 +5455,16 @@ static long kvm_vm_ioctl(struct file filp, r = kvm_gmem_create(kvm, &guest_memfd); break; } + case KVM_LINK_GUEST_MEMFD: { + struct kvm_link_guest_memfd params; + + r = -EFAULT; + if (copy_from_user(&params, argp, sizeof(params))) + goto out; + + r = kvm_gmem_link(kvm, &params); + break; + } #endif default: r = kvm_arch_vm_ioctl(filp, ioctl, arg);
3/2	2026/10/26 07:29	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 11094 output: 34 thoughts: 762 Thoughts: Analyzing the KVM Guest Memfd Link Patch Series Okay, so I need to evaluate this patch series targeted at the amd64 architecture. My understanding is that the goal is to implement a feature for linking guest memory file descriptors (memfds) within the KVM subsystem. Let's break this down systematically. First, I see the documentation has been updated to cover the new `KVM_LINK_GUEST_MEMFD` ioctl and the corresponding capability, `KVM_CAP_GUEST_MEMFD_LINK`. Good, this is essential for userspace understanding. Next, I see that a new function, `kvm_arch_gmem_link_allowed`, has been added to `arch/x86/kvm/x86.c`, and its declaration is in `include/linux/kvm_host.h`. I'll need to understand the architectural implications of this "allowed" check. What are the constraints? What's it preventing? This could be important for security. The core of the functionality appears to be in the include files, particularly `uapi/linux/kvm.h`, where the new capability `KVM_CAP_GUEST_MEMFD_LINK` and the `KVM_LINK_GUEST_MEMFD` ioctl, along with the associated `struct kvm_link_guest_memfd`, are defined. This is where the userspace interface is established. This suggests we are introducing a new ioctl to KVM. There are also selftests in `tools/testing/selftests/kvm/`, so that's good. These should provide a basic level of confidence that the feature works as intended. The main implementation changes are in `virt/kvm/guest_memfd.c`. I see `kvm_arch_gmem_link_allowed` implemented there, which makes sense. There's also some refactoring of `kvm_gmem_alloc_file` and then the new `kvm_gmem_link` function. This is where the core logic of linking the memfds presumably happens. Finally, in `virt/kvm/kvm_main.c`, the patch series handles the new capability and ioctl in the appropriate `kvm_vm_ioctl_check_extension_generic` and `kvm_vm_ioctl` functions, respectively. This is where the ioctl is actually dispatched. Now, the important questions: Is this reachable? KVM is a central piece of virtualization in Linux, so it should be. Userspace can reach it via `/dev/kvm`, creating a VM, and then using the new ioctl. The fact that syzkaller frequently fuzzes KVM is very promising because it means we have a good chance of finding bugs here. KVM is available on amd64 in environments like QEMU, GCE, or KVM. But what about config options? Does `KVM_GUEST_MEMFD` need to be enabled explicitly, or is this enabled by default? I should use `grepper` or equivalent to check the Kconfig for related configurations.
4/2	2026/10/26 07:30	tool	grepper	0m Args: { "Expression": "config KVM_GUEST_MEMFD", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/Kconfig=100=config KVM_MMU_LOCKLESS_AGING\n--\nvirt/kvm/Kconfig-102-\nvirt/kvm/Kconfig:103:config KVM_GUEST_MEMFD\nvirt/kvm/Kconfig-104- select XARRAY_MULTI\n" }
5/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 12650 output: 34 thoughts: 20 Thoughts: Okay, let's dive into this. Here's my take on those instructions, as if they're my internal thought process: Diving into KVM Configuration Alright, time to get my hands dirty and understand how this KVM configuration is structured. Based on what I'm looking for, it looks like I need to zero in on `virt/kvm/Kconfig`. And, based on past experience with these sorts of files, I'm betting the relevant sections are likely to be around line 103. Let's start there.
6/2	2026/10/26 07:30	tool	read-file	0m Args: { "File": "virt/kvm/Kconfig", "FirstLine": 95, "LineCount": 25 } Results: { "Contents": " 95:\t bool\n 96:\t\n 97:\tconfig KVM_ELIDE_TLB_FLUSH_IF_YOUNG\n 98:\t bool\n 99:\t\n 100:\tconfig KVM_MMU_LOCKLESS_AGING\n 101:\t bool\n 102:\t\n 103:\tconfig KVM_GUEST_MEMFD\n 104:\t select XARRAY_MULTI\n 105:\t bool\n 106:\t\n 107:\tconfig HAVE_KVM_ARCH_GMEM_CONVERT\n 108:\t bool\n 109:\t depends on KVM_GUEST_MEMFD\n 110:\t\n 111:\tconfig HAVE_KVM_ARCH_GMEM_RECLAIM\n 112:\t bool\n 113:\t depends on KVM_GUEST_MEMFD\n 114:\t\n 115:\tconfig HAVE_KVM_ARCH_GMEM_INVALIDATE\n 116:\t bool\n 117:\t depends on KVM_GUEST_MEMFD\n 118:\t\n 119:\tconfig HAVE_KVM_ARCH_GMEM_POPULATE\n" }
7/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 13150 output: 23 thoughts: 16 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: Analyzing the Selection of `KVM_GUEST_MEMFD` Right, so the thought process starts with a simple query: who is choosing `KVM_GUEST_MEMFD`? It's immediately about identifying the responsible party, or more likely, the upstream driver/feature that's using this KVM feature. The selection itself is the critical point. We're not just observing its presence; we're interested in the reasoning behind its selection. We're going to want to know what part of the code base is calling into the kernel for a guest memory file descriptor with this particular feature flag. Why is it being used? Is it part of the virtual machine? Is there a driver that's been compiled and is selecting this flag? Essentially, I'm trying to trace the implications: what functionality is leveraging this specific memory access method, and why are they selecting `KVM_GUEST_MEMFD` specifically? Are we looking at a performance optimization, a security measure, a new feature, or something else entirely? The 'who' is just the first step in understanding the broader context and potential design implications of this choice. Understanding the 'why' should be the end goal of this process.
8/2	2026/10/26 07:30	tool	grepper	0m Args: { "Expression": "select KVM_GUEST_MEMFD" } Results: { "Output": "arch/arm64/kvm/Kconfig=20=menuconfig KVM\n--\narch/arm64/kvm/Kconfig-38-\tselect GUEST_PERF_EVENTS if PERF_EVENTS\narch/arm64/kvm/Kconfig:39:\tselect KVM_GUEST_MEMFD\narch/arm64/kvm/Kconfig-40-\thelp\n--\narch/x86/kvm/Kconfig=20=config KVM_X86\n--\narch/x86/kvm/Kconfig-49-\tselect KVM_WERROR if WERROR\narch/x86/kvm/Kconfig:50:\tselect KVM_GUEST_MEMFD if X86_64\narch/x86/kvm/Kconfig-51-\n" }
9/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 13689 output: 37 thoughts: 69 Thoughts: Here's my take on those thoughts: X86 KVM Configuration Deep Dive Okay, so `KVM_X86` is clearly selecting `KVM_GUEST_MEMFD` if we're on X86_64 architecture. That's good to know, but I need to understand the dependencies and the overall x86 KVM enablement process. Time to dig into `arch/x86/kvm/Kconfig`. I need to refresh my memory on what triggers `KVM_X86` and get a clearer picture of how KVM functions on x86, particularly regarding its configuration options. This should give me a better understanding of the underlying choices the system is making here.
10/2	2026/10/26 07:30	tool	read-file	0m Args: { "File": "arch/x86/kvm/Kconfig", "FirstLine": 1, "LineCount": 60 } Results: { "Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0\n 2:\t#\n 3:\t# KVM configuration\n 4:\t#\n 5:\t\n 6:\tsource \"virt/kvm/Kconfig\"\n 7:\t\n 8:\tmenuconfig VIRTUALIZATION\n 9:\t\tbool \"Virtualization\"\n 10:\t\tdefault y\n 11:\t\thelp\n 12:\t\t Say Y here to get to see options for using your Linux host to run other\n 13:\t\t operating systems inside virtual machines (guests).\n 14:\t\t This option alone does not add any kernel code.\n 15:\t\n 16:\t\t If you say N, all options in this submenu will be skipped and disabled.\n 17:\t\n 18:\tif VIRTUALIZATION\n 19:\t\n 20:\tconfig KVM_X86\n 21:\t\tdef_tristate KVM if (KVM_INTEL != n \|\| KVM_AMD != n)\n 22:\t\tselect KVM_COMMON\n 23:\t\tselect KVM_ELIDE_TLB_FLUSH_IF_YOUNG\n 24:\t\tselect KVM_MMU_LOCKLESS_AGING\n 25:\t\tselect HAVE_KVM_IRQCHIP\n 26:\t\tselect HAVE_KVM_PFNCACHE\n 27:\t\tselect HAVE_KVM_DIRTY_RING_TSO\n 28:\t\tselect HAVE_KVM_DIRTY_RING_ACQ_REL\n 29:\t\tselect HAVE_KVM_IRQ_BYPASS\n 30:\t\tselect HAVE_KVM_IRQ_ROUTING\n 31:\t\tselect HAVE_KVM_READONLY_MEM\n 32:\t\tselect VHOST_TASK\n 33:\t\tselect KVM_ASYNC_PF\n 34:\t\tselect USER_RETURN_NOTIFIER\n 35:\t\tselect KVM_MMIO\n 36:\t\tselect SCHED_INFO\n 37:\t\tselect PERF_EVENTS\n 38:\t\tselect GUEST_PERF_EVENTS\n 39:\t\tselect PERF_GUEST_MEDIATED_PMU\n 40:\t\tselect HAVE_KVM_MSI\n 41:\t\tselect HAVE_KVM_CPU_RELAX_INTERCEPT\n 42:\t\tselect HAVE_KVM_NO_POLL\n 43:\t\tselect VIRT_XFER_TO_GUEST_WORK\n 44:\t\tselect KVM_GENERIC_DIRTYLOG_READ_PROTECT\n 45:\t\tselect KVM_VFIO\n 46:\t\tselect HAVE_KVM_PM_NOTIFIER if PM\n 47:\t\tselect KVM_GENERIC_HARDWARE_ENABLING\n 48:\t\tselect KVM_GENERIC_PRE_FAULT_MEMORY\n 49:\t\tselect KVM_WERROR if WERROR\n 50:\t\tselect KVM_GUEST_MEMFD if X86_64\n 51:\t\n 52:\tconfig KVM\n 53:\t\ttristate \"Kernel-based Virtual Machine (KVM) support\"\n 54:\t\tdepends on X86_LOCAL_APIC\n 55:\t\thelp\n 56:\t\t Support hosting fully virtualized guest machines using hardware\n 57:\t\t virtualization extensions. You will need a fairly recent\n 58:\t\t processor equipped with virtualization extensions. You will also\n 59:\t\t need to select one or more of the processor modules below.\n 60:\t\n" }
11/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 14817 output: 38 thoughts: 89 Thoughts: Okay, here's my interpretation of this thought process: KVM Configuration Deep Dive Alright, so I need to figure out the dependencies and implications of KVM configurations. My initial thought is to zero in on `CONFIG_KVM`, which is the core enabling flag. But then it immediately branches out. I'm thinking, "Do I also need `CONFIG_KVM_INTEL` or `CONFIG_KVM_AMD`, or is it the software-based protection flag, `CONFIG_KVM_SW_PROTECTED_VM` that I need? I should clarify that last one; let me double-check the exact symbol." Wait... I'll just look for a symbol like `KVM_SW_PROTECTED_VM`, that should do it. To get a clearer picture of these relationships, I need to get into the details of the Kconfig file for the x86 architecture. I'll need to examine lines 60 through 120 within `arch/x86/kvm/Kconfig`. That section will likely provide the conditional logic, default values, and dependencies I'm looking for. That should give me the configuration relationships I need to be aware of.
12/2	2026/10/26 07:30	tool	read-file	0m Args: { "File": "arch/x86/kvm/Kconfig", "FirstLine": 61, "LineCount": 60 } Results: { "Contents": " 61:\t\t This module provides access to the hardware capabilities through\n 62:\t\t a character device node named /dev/kvm.\n 63:\t\n 64:\t\t To compile this as a module, choose M here: the module\n 65:\t\t will be called kvm.\n 66:\t\n 67:\t\t If unsure, say N.\n 68:\t\n 69:\tconfig KVM_WERROR\n 70:\t\tbool \"Compile KVM with -Werror\"\n 71:\t\t# Disallow KVM's -Werror if KASAN is enabled, e.g. to guard against\n 72:\t\t# randomized configs from selecting KVM_WERROR=y, which doesn't play\n 73:\t\t# nice with KASAN. KASAN builds generates warnings for the default\n 74:\t\t# FRAME_WARN, i.e. KVM_WERROR=y with KASAN=y requires special tuning.\n 75:\t\t# Building KVM with -Werror and KASAN is still doable via enabling\n 76:\t\t# the kernel-wide WERROR=y.\n 77:\t\tdepends on KVM_X86 \u0026\u0026 ((EXPERT \u0026\u0026 !KASAN) \|\| WERROR)\n 78:\t\thelp\n 79:\t\t Add -Werror to the build flags for KVM.\n 80:\t\n 81:\t\t If in doubt, say \"N\".\n 82:\t\n 83:\tconfig KVM_VM_MEMORY_ATTRIBUTES\n 84:\t\tbool \"Enable per-VM PRIVATE vs. SHARED attributes (for CoCo VMs)\"\n 85:\t\tdepends on KVM_SW_PROTECTED_VM \|\| KVM_INTEL_TDX \|\| KVM_AMD_SEV\n 86:\t\thelp\n 87:\t\t Enable support for tracking PRIVATE vs. SHARED memory using per-VM\n 88:\t\t memory attributes. Using per-VM attributes is deprecated in favor of\n 89:\t\t tracking PRIVATE state in guest_memfd. Select this if you need to run\n 90:\t\t CoCo VMs using a VMM that doesn't support guest_memfd memory\n 91:\t\t attributes.\n 92:\t\n 93:\t\t If unsure, say N.\n 94:\t\n 95:\tconfig KVM_SW_PROTECTED_VM\n 96:\t\tbool \"Enable support for KVM software-protected VMs\"\n 97:\t\tdepends on EXPERT\n 98:\t\tdepends on KVM_X86 \u0026\u0026 X86_64\n 99:\t\thelp\n 100:\t\t Enable support for KVM software-protected VMs. Currently, software-\n 101:\t\t protected VMs are purely a development and testing vehicle for\n 102:\t\t KVM_CREATE_GUEST_MEMFD. Attempting to run a \"real\" VM workload as a\n 103:\t\t software-protected VM will fail miserably.\n 104:\t\n 105:\t\t If unsure, say \"N\".\n 106:\t\n 107:\tconfig KVM_INTEL\n 108:\t\ttristate \"KVM for Intel (and compatible) processors support\"\n 109:\t\tdepends on KVM \u0026\u0026 IA32_FEAT_CTL\n 110:\t\tselect X86_FRED if X86_64\n 111:\t\thelp\n 112:\t\t Provides support for KVM on processors equipped with Intel's VT\n 113:\t\t extensions, a.k.a. Virtual Machine Extensions (VMX).\n 114:\t\n 115:\t\t To compile this as a module, choose M here: the module\n 116:\t\t will be called kvm-intel.\n 117:\t\n 118:\tconfig KVM_INTEL_PROVE_VE\n 119:\t bool \"Check that guests do not receive #VE exceptions\"\n 120:\t depends on KVM_INTEL \u0026\u0026 EXPERT\n" }
13/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 16198 output: 32 thoughts: 77 Thoughts: Here's my thought process, as if I were considering this issue: Delving into Software-Protected VMs and `guest_memfd` Okay, so I'm thinking about `KVM_SW_PROTECTED_VM`. I know it enables software-protected VMs. But here's the crucial question: does `guest_memfd` require that flag, or can it function on a standard KVM setup? I need to clarify that dependency. The obvious next step is to examine the code. I'll need to dig into `kvm_gmem_create` and, more specifically, `guest_memfd.c`. Those are the obvious places where this dependency will be spelled out. I need to understand the relationship between software-protected VMs and this memory file descriptor functionality. Hopefully the code will be self-documenting.
14/2	2026/10/26 07:30	tool	grepper	0m Args: { "Expression": "kvm_gmem_create", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/guest_memfd.c=953=static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode,\n--\nvirt/kvm/guest_memfd.c-989-\nvirt/kvm/guest_memfd.c:990:static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags)\nvirt/kvm/guest_memfd.c-991-{\n--\nvirt/kvm/guest_memfd.c-1026-\nvirt/kvm/guest_memfd.c:1027:int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args)\nvirt/kvm/guest_memfd.c-1028-{\n--\nvirt/kvm/guest_memfd.c-1037-\nvirt/kvm/guest_memfd.c:1038:\treturn __kvm_gmem_create(kvm, size, flags);\nvirt/kvm/guest_memfd.c-1039-}\n--\nvirt/kvm/guest_memfd.h=9=void kvm_gmem_exit(void);\nvirt/kvm/guest_memfd.h:10:int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args);\nvirt/kvm/guest_memfd.h-11-int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args);\n--\nvirt/kvm/kvm_main.c=5227=static long kvm_vm_ioctl(struct file *filp,\n--\nvirt/kvm/kvm_main.c-5454-\nvirt/kvm/kvm_main.c:5455:\t\tr = kvm_gmem_create(kvm, \u0026guest_memfd);\nvirt/kvm/kvm_main.c-5456-\t\tbreak;\n" }
15/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 17017 output: 40 thoughts: 34 Thoughts: Here's a summary of my thought process: Diving into Guest Memory Management Okay, let's zoom in on something specific. I need to understand how guest memory is managed, especially how it's created, and how it interacts with memory file descriptors. My starting point will be the `kvm_gmem_create` function. I remember seeing a lot of interesting stuff there. Then, let's zero in on `guest_memfd.c`, specifically lines 1020 through 1045. That specific block should provide a critical piece to the puzzle, likely pertaining to the interaction or setup of memory file descriptors and guest memory regions. By carefully reviewing those lines in the code, I hope to gain clarity on the memory allocation process, memory region mapping, and maybe even find some clues about how memory file descriptors are integrated into the overall architecture. I anticipate these lines will reveal the mechanics of virtualized memory management, which I can then leverage for this research.
16/2	2026/10/26 07:30	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 1020, "LineCount": 30 } Results: { "Contents": "1020:\terr_inode:\n1021:\t\tiput(inode);\n1022:\terr_fd:\n1023:\t\tput_unused_fd(fd);\n1024:\t\treturn err;\n1025:\t}\n1026:\t\n1027:\tint kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args)\n1028:\t{\n1029:\t\tloff_t size = args-\u003esize;\n1030:\t\tu64 flags = args-\u003eflags;\n1031:\t\n1032:\t\tif (flags \u0026 ~kvm_gmem_get_supported_flags(kvm))\n1033:\t\t\treturn -EINVAL;\n1034:\t\n1035:\t\tif (size \u003c= 0 \|\| !PAGE_ALIGNED(size))\n1036:\t\t\treturn -EINVAL;\n1037:\t\n1038:\t\treturn __kvm_gmem_create(kvm, size, flags);\n1039:\t}\n1040:\t\n1041:\tint kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args)\n1042:\t{\n1043:\t\tstatic const char name = \"[kvm-gmem]\";\n1044:\t\tu64 flags = args-\u003eflags;\n1045:\t\tu64 valid_flags = 0;\n1046:\t\tstruct file dst_file, src_file;\n1047:\t\tstruct gmem_file gmem;\n1048:\t\tstruct timespec64 ts;\n1049:\t\tstruct inode *inode;\n" }
17/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 17753 output: 39 thoughts: 89 Thoughts: Here's my thought process, as requested: Investigating `kvm_gmem_get_supported_flags` Alright, let's dive into this. The first step is to figure out the definition of `kvm_gmem_get_supported_flags`. Where is this function declared, ultimately? The text points me towards `include/linux/kvm_host.h`. Good, good... let's check it. The code snippet shows it's an `inline` function declared within that header: ```c static inline u64 kvm_gmem_get_supported_flags(struct kvm *kvm) ``` Now, I'll need to locate that function within `kvm_host.h`. The text suggests checking around line 2585. That's my starting point. I'll need to read the surrounding context to understand its purpose and how it fits into the broader KVM architecture, specifically related to guest memory management. Let's see what we can find.
18/2	2026/10/26 07:30	tool	read-file	0m Args: { "File": "include/linux/kvm_host.h", "FirstLine": 2580, "LineCount": 40 } Results: { "Contents": "2580:\t{\n2581:\t\treturn false;\n2582:\t}\n2583:\t#endif /* kvm_arch_has_private_mem /\n2584:\t\n2585:\t#ifdef CONFIG_KVM_GUEST_MEMFD\n2586:\tbool kvm_gmem_is_private_gfn(struct kvm kvm, gfn_t gfn);\n2587:\tbool kvm_arch_supports_gmem_init_shared(struct kvm kvm);\n2588:\tbool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src);\n2589:\t\n2590:\tstatic inline u64 kvm_gmem_get_supported_flags(struct kvm kvm)\n2591:\t{\n2592:\t\tu64 flags = GUEST_MEMFD_FLAG_MMAP;\n2593:\t\n2594:\t\tif (!kvm \|\| kvm_arch_supports_gmem_init_shared(kvm))\n2595:\t\t\tflags \|= GUEST_MEMFD_FLAG_INIT_SHARED;\n2596:\t\n2597:\t\treturn flags;\n2598:\t}\n2599:\t\n2600:\tint kvm_gmem_get_pfn(struct kvm kvm, struct kvm_memory_slot slot,\n2601:\t\t\t gfn_t gfn, kvm_pfn_t pfn, int max_order);\n2602:\t#else\n2603:\tstatic inline int kvm_gmem_get_pfn(struct kvm kvm,\n2604:\t\t\t\t\t struct kvm_memory_slot slot, gfn_t gfn,\n2605:\t\t\t\t\t kvm_pfn_t pfn, int max_order)\n2606:\t{\n2607:\t\tKVM_BUG_ON(1, kvm);\n2608:\t\treturn -EIO;\n2609:\t}\n2610:\t#endif /* CONFIG_KVM_GUEST_MEMFD /\n2611:\t\n2612:\tint kvm_arch_gmem_make_private(struct kvm kvm, gfn_t gfn, kvm_pfn_t pfn,\n2613:\t\t\t\t kvm_pfn_t nr_pages);\n2614:\tvoid kvm_arch_gmem_make_shared(kvm_pfn_t pfn, kvm_pfn_t nr_pages);\n2615:\t#ifndef CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT\n2616:\t#define kvm_arch_has_gmem_convert() false\n2617:\t#endif\n2618:\t\n2619:\t#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_POPULATE\n" }
19/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 18866 output: 29 thoughts: 1269 Thoughts: KVM Guest Memfd Link Ioctl: A Deep Dive Okay, so on x86_64, `KVM_GUEST_MEMFD` is automatically selected by `KVM_X86`. Let's confirm that: the `Kconfig` files clearly show `KVM_X86` selects `KVM_GUEST_MEMFD` if it's an amd64 target. `KVM_X86` is enabled when `KVM` is enabled and either `KVM_INTEL` or `KVM_AMD` are enabled. So if KVM is enabled, and intel or amd KVM is enabled, then this feature is too. Now, let's break down this patch. It introduces a new ioctl, `KVM_LINK_GUEST_MEMFD`, and a related capability, `KVM_CAP_GUEST_MEMFD_LINK`. Diving into `guest_memfd.c`, I see a refactored `kvm_gmem_alloc_file`. This function now handles file allocation, and initializes a `gmem_file` structure. The new `kvm_gmem_link` function is where the magic happens, specifically by connecting existing guest memfd inodes to a new VM. This function checks flags, file descriptor validity, and makes sure we're not trying to link the same VM. It's calling `fdget`, gets the inode, calls `ihold`, then allocates a new `gmem_file` for it, updates timestamps, and installs the new file descriptor. Crucially, in `arch/x86/kvm/x86.c`, `kvm_arch_gmem_link_allowed` only allows linking if the VM types are the same, which is a good sanity check. Now, let's consider the triage. Given the system is configured to support KVM and has nested virtualization or KVM, this patch is immediately relevant. `/dev/kvm` is standard. Syzkaller heavily targets KVM, so this is definitely something worth pursuing. Why? Because this new API, `KVM_LINK_GUEST_MEMFD`, allows sharing of guest memfd inodes between different VMs! This has significant implications. We're talking about multiple VMs pointing to the same memory, xarray bindings, synchronization with `filemap_invalidate_lock`, and shared inode lifecycle, all of which are classic sources for race conditions, especially given the memory attributes. Think concurrency, lifecycle, reference counting, and potential memory-related races! This is definitely `WorthFuzzing=true`. Let's quickly verify the configuration: I need to check how `guest_memfd.c` is compiled using the `Makefile` in `virt/kvm/`. I need to ensure all the dependencies are met.
20/2	2026/10/26 07:30	tool	grepper	0m Args: { "Expression": "guest_memfd", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/Makefile.kvm=14=kvm-$(CONFIG_HAVE_KVM_PFNCACHE) += $(KVM)/pfncache.o\nvirt/kvm/Makefile.kvm:15:kvm-$(CONFIG_KVM_GUEST_MEMFD) += $(KVM)/guest_memfd.o\n--\nvirt/kvm/guest_memfd.c-13-#include \"kvm_mm.h\"\nvirt/kvm/guest_memfd.c:14:#include \"guest_memfd.h\"\nvirt/kvm/guest_memfd.c-15-\nvirt/kvm/guest_memfd.c=16=static struct vfsmount kvm_gmem_mnt;\n--\nvirt/kvm/guest_memfd.c-18-/\nvirt/kvm/guest_memfd.c:19: * A guest_memfd instance can be associated multiple VMs, each with its own\nvirt/kvm/guest_memfd.c-20- * \"view\" of the underlying physical memory.\n--\nvirt/kvm/guest_memfd.c=129=static struct folio kvm_gmem_get_folio(struct inode inode, pgoff_t index)\n--\nvirt/kvm/guest_memfd.c-150-\t * External interfaces like kvm_gmem_get_pfn() support dealing\nvirt/kvm/guest_memfd.c:151:\t * with hugepages to a degree, but internally, guest_memfd currently\nvirt/kvm/guest_memfd.c-152-\t * assumes that all folios are order-0 and handling would need\n--\nvirt/kvm/guest_memfd.c=541=bool kvm_gmem_is_private_gfn(struct kvm kvm, gfn_t gfn)\n--\nvirt/kvm/guest_memfd.c-558-\t caller _must_ protect consumption of private vs. shared either by\nvirt/kvm/guest_memfd.c:559:\t * holding guest_memfd's invalidate lock for the entire duration, or by\nvirt/kvm/guest_memfd.c-560-\t * checking mmu_invalidate_retry_gfn() under mmu_lock to serialize\n--\nvirt/kvm/guest_memfd.c=685=static int __kvm_gmem_set_attributes(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-730-\t/\nvirt/kvm/guest_memfd.c:731:\t * From this point on guest_memfd has performed necessary\nvirt/kvm/guest_memfd.c-732-\t * checks and can proceed to do guest-breaking changes.\n--\nvirt/kvm/guest_memfd.c=890=bool __weak kvm_arch_supports_gmem_init_shared(struct kvm kvm)\n--\nvirt/kvm/guest_memfd.c-895-/\nvirt/kvm/guest_memfd.c:896: * Returns true if a guest_memfd instance associated with @src may be linked\nvirt/kvm/guest_memfd.c-897- * into @dst, i.e. if both VMs can safely share the underlying memory.\n--\nvirt/kvm/guest_memfd.c=904=static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags)\n--\nvirt/kvm/guest_memfd.c-917-\t/\nvirt/kvm/guest_memfd.c:918:\t * guest_memfd memory is neither migratable nor swappable: set\nvirt/kvm/guest_memfd.c-919-\t * inaccessible to gate off both.\n--\nvirt/kvm/guest_memfd.c-949-/\nvirt/kvm/guest_memfd.c:950: Allocate a new guest_memfd file for @kvm that refers to @inode. On success,\nvirt/kvm/guest_memfd.c-951- * the returned file takes over the caller's reference to @inode.\n--\nvirt/kvm/guest_memfd.c=990=static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags)\n--\nvirt/kvm/guest_memfd.c-1026-\nvirt/kvm/guest_memfd.c:1027:int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args)\nvirt/kvm/guest_memfd.c-1028-{\n--\nvirt/kvm/guest_memfd.c-1040-\nvirt/kvm/guest_memfd.c:1041:int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args)\nvirt/kvm/guest_memfd.c-1042-{\n--\nvirt/kvm/guest_memfd.c=1408=static void kvm_gmem_init_inode_once(void __gi)\n--\nvirt/kvm/guest_memfd.c-1413-\t * Note! Don't initialize the inode with anything specific to the\nvirt/kvm/guest_memfd.c:1414:\t * guest_memfd instance, or that might be specific to how the inode is\nvirt/kvm/guest_memfd.c-1415-\t * used (from the VFS-layer's perspective). This hook is called only\n--\nvirt/kvm/guest_memfd.c=1447=static void kvm_gmem_destroy_inode(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-1456-\t initialized, i.e. if the inode is being destroyed before\nvirt/kvm/guest_memfd.c:1457:\t * guest_memfd can set the external lock, lockdep would find\nvirt/kvm/guest_memfd.c-1458-\t * that the tree's internal ma_lock was not held.\n--\nvirt/kvm/guest_memfd.c=1496=static struct file_system_type kvm_gmem_fs = {\nvirt/kvm/guest_memfd.c:1497:\t.name\t\t = \"guest_memfd\",\nvirt/kvm/guest_memfd.c-1498-\t.init_fs_context = kvm_gmem_init_fs_context,\n--\nvirt/kvm/guest_memfd.h=9=void kvm_gmem_exit(void);\nvirt/kvm/guest_memfd.h:10:int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args);\nvirt/kvm/guest_memfd.h:11:int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args);\nvirt/kvm/guest_memfd.h-12-int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot,\n--\nvirt/kvm/kvm_main.c-58-#include \"async_pf.h\"\nvirt/kvm/kvm_main.c:59:#include \"guest_memfd.h\"\nvirt/kvm/kvm_main.c-60-#include \"kvm_mm.h\"\n--\nvirt/kvm/kvm_main.c=1705=static void kvm_commit_memory_region(struct kvm kvm,\n--\nvirt/kvm/kvm_main.c-1738-\t\t/\nvirt/kvm/kvm_main.c:1739:\t\t * Moving a guest_memfd memslot isn't supported, and will never\nvirt/kvm/kvm_main.c-1740-\t\t * be supported.\n--\nvirt/kvm/kvm_main.c-1753-\t\t * TODO: Drop the WARN and do the unbind() call only for MOVE\nvirt/kvm/kvm_main.c:1754:\t\t * when dirty logging guest_memfd memslots is supported. Until\nvirt/kvm/kvm_main.c:1755:\t\t * then, flags-only changes on guest_memfd slots should also be\nvirt/kvm/kvm_main.c-1756-\t\t * impossible; unbind the old memslot for defense-in-depth.\n--\nvirt/kvm/kvm_main.c=2013=static int kvm_set_memory_region(struct kvm kvm,\n--\nvirt/kvm/kvm_main.c-2045-\tif (mem-\u003eflags \u0026 KVM_MEM_GUEST_MEMFD \u0026\u0026\nvirt/kvm/kvm_main.c:2046:\t (mem-\u003eguest_memfd_offset \u0026 (PAGE_SIZE - 1) \|\|\nvirt/kvm/kvm_main.c:2047:\t mem-\u003eguest_memfd_offset + mem-\u003ememory_size \u003c mem-\u003eguest_memfd_offset))\nvirt/kvm/kvm_main.c-2048-\t\treturn -EINVAL;\n--\nvirt/kvm/kvm_main.c-2126-\tif (change == KVM_MR_CREATE \u0026\u0026 (mem-\u003eflags \u0026 KVM_MEM_GUEST_MEMFD)) {\nvirt/kvm/kvm_main.c:2127:\t\tr = kvm_gmem_prepare_memory_region(kvm, new, mem-\u003eguest_memfd,\nvirt/kvm/kvm_main.c:2128:\t\t\t\t\t\t mem-\u003eguest_memfd_offset);\nvirt/kvm/kvm_main.c-2129-\t\tif (r)\n--\nvirt/kvm/kvm_main.c=5227=static long kvm_vm_ioctl(struct file filp,\n--\nvirt/kvm/kvm_main.c-5448-\tcase KVM_CREATE_GUEST_MEMFD: {\nvirt/kvm/kvm_main.c:5449:\t\tstruct kvm_create_guest_memfd guest_memfd;\nvirt/kvm/kvm_main.c-5450-\nvirt/kvm/kvm_main.c-5451-\t\tr = -EFAULT;\nvirt/kvm/kvm_main.c:5452:\t\tif (copy_from_user(\u0026guest_memfd, argp, sizeof(guest_memfd)))\nvirt/kvm/kvm_main.c-5453-\t\t\tgoto out;\nvirt/kvm/kvm_main.c-5454-\nvirt/kvm/kvm_main.c:5455:\t\tr = kvm_gmem_create(kvm, \u0026guest_memfd);\nvirt/kvm/kvm_main.c-5456-\t\tbreak;\n--\nvirt/kvm/kvm_main.c-5458-\tcase KVM_LINK_GUEST_MEMFD: {\nvirt/kvm/kvm_main.c:5459:\t\tstruct kvm_link_guest_memfd params;\nvirt/kvm/kvm_main.c-5460-\n" }
21/2	2026/10/26 07:30	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 23628 output: 31 thoughts: 1259 Thoughts: Analyzing KVM Guest Memfd for Fuzzing Focus Okay, let's break this down. My goal is to identify the key functions for fuzzing this KVM guest memfd feature. I need to figure out which functions are new, specific to the added functionality, and not ubiquitous kernel routines. First, I looked at the configuration dependencies. `CONFIG_KVM_GUEST_MEMFD` is the key. It's a boolean, selected by `KVM_X86`, which in turn depends on `KVM_INTEL` or `KVM_AMD` and requires `X86_64`. So, for x86-64 guests, we're looking at KVM with either Intel or AMD virtualization enabled, and that also enables `KVM_GUEST_MEMFD`. Good to know. This information is important for setup but does not highlight specific functions. Now, let's get into the code. I found that the `virt/kvm/guest_memfd.c` file is the heart of the changes. The `kvm_main.c` file includes the relevant ifdefs. I see two key ioctl calls `KVM_CREATE_GUEST_MEMFD` and `KVM_LINK_GUEST_MEMFD` related to this feature. This is the API surface. Looking at the rules for FocusSymbols, I need to pinpoint the feature-specific logic and entry points. I should avoid generic functions like allocators or sync primitives. I should look at new or altered functions that implement the memfd linking logic. Here are the focus functions I've identified: 1. `kvm_gmem_link`: This is a non-static, KVM subsystem exported function that implements the `KVM_LINK_GUEST_MEMFD` ioctl logic. This is a direct entry point. 2. `kvm_arch_gmem_link_allowed`: A new non-static function in `arch/x86/kvm/x86.c` which, I think, checks the architecture requirements for the link. Another entrypoint. 3. `kvm_gmem_create`: A non-static caller that implements the `KVM_CREATE_GUEST_MEMFD` ioctl logic. Another direct entry point. 4. `__kvm_gmem_create`: A static function that creates the memfd. It should not be added to FocusSymbols unless it is somehow unique. 5. `kvm_gmem_alloc_file`: A static helper in `virt/kvm/guest_memfd.c`, called by other functions. I need to be careful with this one. Since it is static, it could be inlined. The focus should be around creating a new file descriptor, linking it, creating it, and checking if the link is allowed. Therefore, for fuzzing, I'm leaning toward these as the critical functions: `kvm_gmem_link`, `kvm_gmem_create` and `kvm_arch_gmem_link_allowed`. I should also inspect `virt/kvm/guest_memfd.c` more thoroughly to understand how `gmem_file` and `gmem_inode` are used and what happens when the guest memfd file is linked and bound.
22/2	2026/10/26 07:31	tool	grepper	0m Args: { "Expression": "gmem_file_list", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/guest_memfd.c=33=struct gmem_inode {\n--\nvirt/kvm/guest_memfd.c-35-\tstruct inode vfs_inode;\nvirt/kvm/guest_memfd.c:36:\tstruct list_head gmem_file_list;\nvirt/kvm/guest_memfd.c-37-\n--\nvirt/kvm/guest_memfd.c=48=static __always_inline struct gmem_inode GMEM_I(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-53-#define kvm_gmem_for_each_file(f, inode) \\\nvirt/kvm/guest_memfd.c:54:\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\nvirt/kvm/guest_memfd.c-55-\n--\nvirt/kvm/guest_memfd.c=953=static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode,\n--\nvirt/kvm/guest_memfd.c-983-\tfilemap_invalidate_lock(inode-\u003ei_mapping);\nvirt/kvm/guest_memfd.c:984:\tlist_add(\u0026f-\u003eentry, \u0026GMEM_I(inode)-\u003egmem_file_list);\nvirt/kvm/guest_memfd.c-985-\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n--\nvirt/kvm/guest_memfd.c=1423=static struct inode kvm_gmem_alloc_inode(struct super_block *sb)\n--\nvirt/kvm/guest_memfd.c-1442-\tgi-\u003eflags = 0;\nvirt/kvm/guest_memfd.c:1443:\tINIT_LIST_HEAD(\u0026gi-\u003egmem_file_list);\nvirt/kvm/guest_memfd.c-1444-\treturn \u0026gi-\u003evfs_inode;\n" }
23/2	2026/10/26 07:31	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 26158 output: 36 thoughts: 21 Thoughts: Okay, let's dive into this code. Investigating `kvm_gmem_for_each_file` Usage Alright, so I need to understand the implications of this function, `kvm_gmem_for_each_file`. My initial thought is to trace its usage. I'll need to see precisely where `kvm_gmem_for_each_file` is invoked within the kernel's KVM code. Understanding the contexts will give me a good handle on its purpose. Knowing who uses it will tell me what systems, subsystems or routines depend on it. This is the first step in deciphering its overall role within the KVM hypervisor. My next thought is, how many places use it? Where is the code located? Let's get to work!
24/2	2026/10/26 07:31	tool	grepper	0m Args: { "Expression": "kvm_gmem_for_each_file", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/guest_memfd.c=48=static __always_inline struct gmem_inode GMEM_I(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-52-\nvirt/kvm/guest_memfd.c:53:#define kvm_gmem_for_each_file(f, inode) \\\nvirt/kvm/guest_memfd.c-54-\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\n--\nvirt/kvm/guest_memfd.c=213=static void kvm_gmem_invalidate_start(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-218-\nvirt/kvm/guest_memfd.c:219:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c-220-\t\t__kvm_gmem_invalidate_start(f, start, end, filter);\n--\nvirt/kvm/guest_memfd.c=235=static void kvm_gmem_invalidate_end(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-239-\nvirt/kvm/guest_memfd.c:240:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c-241-\t\t__kvm_gmem_invalidate_end(f, start, end);\n" }
25/2	2026/10/26 07:31	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 26796 output: 32 thoughts: 127 Thoughts: Analyzing the KVM Global Memory Invalidation Code Okay, so I'm looking at this code and immediately I see something interesting: in `kvm_gmem_invalidate_start` and `kvm_gmem_invalidate_end`, there's iteration happening over `gmem_file_list`. This is the key. Before this patch, the list supposedly only had one `gmem_file` entry per inode, right? But now, with the changes, we're dealing with potentially multiple `gmem_file` structures attached to the same inode! Different VMs are sharing the same underlying inode through this mechanism. Interesting. Alright, so the critical question now is, what happens when we release a `gmem_file`? Since this is a list that potentially has more than one entry per inode, what does the release procedure do? Time to search for where this is handled... let's look for `kvm_gmem_fops` and/or the `release` function... that's where the heart of the matter must be.
26/2	2026/10/26 07:31	tool	grepper	0m Args: { "Expression": "kvm_gmem_release", "PathPrefixes": [ "virt/kvm" ] } Results: { "Output": "virt/kvm/guest_memfd.c=314=static long kvm_gmem_fallocate(struct file file, int mode, loff_t offset,\n--\nvirt/kvm/guest_memfd.c-337-\nvirt/kvm/guest_memfd.c:338:static int kvm_gmem_release(struct inode inode, struct file file)\nvirt/kvm/guest_memfd.c-339-{\n--\nvirt/kvm/guest_memfd.c-378-\t slot-\u003egmem.file == A\nvirt/kvm/guest_memfd.c:379:\t \t\t\t\t\tkvm_gmem_release())\nvirt/kvm/guest_memfd.c-380-\t \t\t\t\t\t slot-\u003egmem.file = NULL\n--\nvirt/kvm/guest_memfd.c=427=static inline struct file kvm_gmem_get_file(struct kvm_memory_slot slot)\n--\nvirt/kvm/guest_memfd.c-431-\t * there might be some time between the last fput() and when\nvirt/kvm/guest_memfd.c:432:\t * kvm_gmem_release() clears slot-\u003egmem.file.\nvirt/kvm/guest_memfd.c-433-\t /\n--\nvirt/kvm/guest_memfd.c=809=static struct file_operations kvm_gmem_fops = {\n--\nvirt/kvm/guest_memfd.c-811-\t.open\t\t= generic_file_open,\nvirt/kvm/guest_memfd.c:812:\t.release\t= kvm_gmem_release,\nvirt/kvm/guest_memfd.c-813-\t.fallocate\t= kvm_gmem_fallocate,\n--\nvirt/kvm/guest_memfd.c=1195=void kvm_gmem_unbind(struct kvm_memory_slot slot)\n--\nvirt/kvm/guest_memfd.c-1203-\t * Nothing to do if the underlying file was _already_ closed, as\nvirt/kvm/guest_memfd.c:1204:\t * kvm_gmem_release() invalidates and nullifies all bindings.\nvirt/kvm/guest_memfd.c-1205-\t /\n--\nvirt/kvm/guest_memfd.c-1210-\t However, if the file is _being_ closed, then the bindings need to be\nvirt/kvm/guest_memfd.c:1211:\t * removed as kvm_gmem_release() might not run until after the memslot\nvirt/kvm/guest_memfd.c-1212-\t * is freed. Modifying the bindings is safe even if the file is dying\nvirt/kvm/guest_memfd.c:1213:\t * as kvm_gmem_release() nullifies slot-\u003egmem.file under slots_lock,\nvirt/kvm/guest_memfd.c-1214-\t * and only puts its reference to KVM after destroying all bindings.\nvirt/kvm/guest_memfd.c:1215:\t * I.e. reaching this point means kvm_gmem_release() hasn't destroyed\nvirt/kvm/guest_memfd.c-1216-\t * the bindings or freed the gmem_file and can't do so until the caller\n" }
27/2	2026/10/26 07:31	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 28052 output: 39 thoughts: 27 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience: Analyzing `kvm_gmem_release` in `virt/kvm/guest_memfd.c` Alright, let's dive into `kvm_gmem_release`. I need to refresh my memory on how this function handles the lifecycle of guest memory backed by memfds. I'm immediately interested in the interplay between the userspace memory descriptors and the kernel's tracking. My primary concern is always resource management. I want to understand: is this function robust against potential race conditions, especially when dealing with multiple VMs or processes accessing the same memfd-backed memory? Are there any obvious areas for deadlocks or double-frees? I'm particularly looking for how `kvm_gmem_release` handles the reference counting. How is the lifetime of the guest memory region tied to the memfd's lifecycle, and how are errors handled if the underlying memfd has already been closed? Does the code properly synchronize access to shared structures, particularly during VM exit/entry and when dealing with multiple vCPUs? Any chance of memory leaks if this function fails partway through its process? From a performance perspective, I'm curious about the overhead of freeing this gmem structure and associated resources in comparison to traditional memory management techniques. How does this compare to, say, using hugetlbfs or shared memory segments in terms of performance? Are there any opportunities for optimization within `kvm_gmem_release` itself? Are there any notable differences in the implementation from older kernel releases or different architectures? I need to look for any possible regression or subtle behavior changes.
28/2	2026/10/26 07:31	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 338, "LineCount": 55 } Results: { "Contents": " 338:\tstatic int kvm_gmem_release(struct inode inode, struct file file)\n 339:\t{\n 340:\t\tstruct gmem_file f = file-\u003eprivate_data;\n 341:\t\tstruct kvm_memory_slot slot;\n 342:\t\tstruct kvm kvm = f-\u003ekvm;\n 343:\t\tunsigned long index;\n 344:\t\n 345:\t\t/\n 346:\t\t * Prevent concurrent attempts to unbind a memslot. This is the last\n 347:\t\t * reference to the file and thus no new bindings can be created, but\n 348:\t\t * dereferencing the slot for existing bindings needs to be protected\n 349:\t\t * against memslot updates, specifically so that unbind doesn't race\n 350:\t\t * and free the memslot (kvm_gmem_get_file() will return NULL).\n 351:\t\t /\n 352:\t\tmutex_lock(\u0026kvm-\u003eslots_lock);\n 353:\t\n 354:\t\tfilemap_invalidate_lock(inode-\u003ei_mapping);\n 355:\t\n 356:\t\t/\n 357:\t\t * Note! synchronize_srcu() is _not_ needed after nullifying memslot\n 358:\t\t * bindings as slot-\u003egmem.file cannot be set back to a non-null value\n 359:\t\t * without the memslot first being deleted. I.e. this relies on the\n 360:\t\t * synchronize_srcu_expedited() in kvm_swap_active_memslots() to ensure\n 361:\t\t * kvm_gmem_get_pfn() (which runs with kvm-\u003esrcu held for read) can't\n 362:\t\t * grab a reference to slot-\u003egmem.file even if the struct file object\n 363:\t\t * is reallocated (for use as a different file).\n 364:\t\t \n 365:\t\t file_ref_put() provides a full barrier, and __get_file_rcu() the\n 366:\t\t * matching acquire barrier, to ensure that kvm_gmem_get_file() (via\n 367:\t\t * __get_file_rcu()) sees refcount==0 or fails the \"file reloaded\"\n 368:\t\t * check (file != NULL due to nullifying the file pointer here).\n 369:\t\t \n 370:\t\t Unlike most other users of get_file_rcu(), where callers don't care\n 371:\t\t * if they race with a write, only that they have a reference to _a_\n 372:\t\t * live file, kvm_gmem_get_pfn() needs to get the exact file that is\n 373:\t\t * associated with the memslot. Without the aforementioned SRCU\n 374:\t\t * synchronization, the following could happen:\n 375:\t\t \n 376:\t\t CPU0\t\t\t\tCPU1\n 377:\t\t * kvm_gmem_get_pfn()\n 378:\t\t * slot-\u003egmem.file == A\n 379:\t\t \t\t\t\t\tkvm_gmem_release())\n 380:\t\t \t\t\t\t\t slot-\u003egmem.file = NULL\n 381:\t\t \n 382:\t\t \t\t\t\t\tkvm_set_memory_region()\n 383:\t\t \t\t\t\t\t slot deleted\n 384:\t\t \n 385:\t\t \t\t\t\t\tkvm_set_memory_region()\n 386:\t\t \t\t\t\t\t slot created\n 387:\t\t \t\t\t\t\t slot-\u003egmem.file = B (alloc the same object)\n 388:\t\t \n 389:\t\t * get_file_active()\n 390:\t\t * file = B\n 391:\t\t * file_reloaded = B\n 392:\t\t *\n" }
29/2	2026/10/26 07:31	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 29460 output: 39 thoughts: 16 Thoughts: Okay, here's my interpretation of that thought process, tailored for an expert audience, and written in the first person: Diving Deeper into `kvm_gmem_release` Alright, so we're looking at `kvm_gmem_release`, and I need to understand its implications more thoroughly. The high-level function name is pretty clear, but I know better than to just assume. My mind immediately begins dissecting the context: what data structures is it operating on? What resources are being freed? Are there any potential race conditions I should be on the lookout for? I expect the standard checks for null pointers, but the devil, as always, is in the details. What kind of memory management is this utilizing? Is it simply `kfree` or are there more complex reference counting schemes or perhaps some interaction with page tables? I anticipate looking for side effects related to this function. This will require following the execution path to determine who calls it and when. This could be triggered by VM shutdown, resource exhaustion, or even during live migration. Understanding these triggering events is crucial for debugging and optimization. Let's dig in and see exactly what's happening.
30/2	2026/10/26 07:32	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 393, "LineCount": 40 } Results: { "Contents": " 393:\t\t * \u003cKVM does weird things with an old memslot + new file\u003e\n 394:\t\t \n 395:\t\t Obviously KVM would be broken in many places if the synchronization\n 396:\t\t * were omitted, but it's important to note that get_file_active() does\n 397:\t\t * NOT guarantee a reference to the \"original\" file was obtained, only\n 398:\t\t * that it grabbed a reference for the returned file, i.e. didn't grab\n 399:\t\t * a reference for file A, but then returned a pointer to file B.\n 400:\t\t /\n 401:\t\txa_for_each(\u0026f-\u003ebindings, index, slot)\n 402:\t\t\tWRITE_ONCE(slot-\u003egmem.file, NULL);\n 403:\t\n 404:\t\t/\n 405:\t\t * All in-flight operations are gone and new bindings can be created.\n 406:\t\t * Zap all SPTEs pointed at by this file. Do not free the backing\n 407:\t\t * memory, as its lifetime is associated with the inode, not the file.\n 408:\t\t /\n 409:\t\t__kvm_gmem_invalidate_start(f, 0, -1ul,\n 410:\t\t\t\t\t kvm_gmem_get_all_gfns_filter(inode));\n 411:\t\t__kvm_gmem_invalidate_end(f, 0, -1ul);\n 412:\t\n 413:\t\tlist_del(\u0026f-\u003eentry);\n 414:\t\n 415:\t\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n 416:\t\n 417:\t\tmutex_unlock(\u0026kvm-\u003eslots_lock);\n 418:\t\n 419:\t\txa_destroy(\u0026f-\u003ebindings);\n 420:\t\tkfree(f);\n 421:\t\n 422:\t\tkvm_put_kvm(kvm);\n 423:\t\n 424:\t\treturn 0;\n 425:\t}\n 426:\t\n 427:\tstatic inline struct file kvm_gmem_get_file(struct kvm_memory_slot slot)\n 428:\t{\n 429:\t\t/\n 430:\t\t * Do not return slot-\u003egmem.file if it has already been closed;\n 431:\t\t * there might be some time between the last fput() and when\n 432:\t\t * kvm_gmem_release() clears slot-\u003egmem.file.\n" }
31/2	2026/10/26 07:32	llm	patch-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 30428 output: 226 thoughts: 2528 Thoughts: Fuzzing Guest Memfd Linking in KVM: A Deep Dive Okay, so I've been digging into this `KVM_LINK_GUEST_MEMFD` feature and it's pretty juicy. It's essentially introducing a new way for multiple VMs to share the same underlying memory via a `guest_memfd` file descriptor, and that's opening up a whole new can of worms that needs fuzzing. We've got `kvm_gmem_alloc_file` adding file entries to a shared list (`gmem_file_list`), `kvm_gmem_release` removing them with a lock held on the inode mapping and potential concurrency issues with invalidation callbacks (`kvm_gmem_invalidate_start`, `kvm_gmem_invalidate_end`), release, memory slot bindings, etc. It's all starting to click together into a complex system. This refactoring of `__kvm_gmem_create` and addition of `kvm_gmem_link` and `kvm_arch_gmem_link_allowed` just screams race conditions and use-after-free bugs. I've been thinking about what functions to focus on. We don't want to get lost in the weeds with generic code. We need to zero in on the parts that are actually new or changed. So, after some thought, I've identified the key functions: `kvm_gmem_link`, which is the core of this new feature; `kvm_arch_gmem_link_allowed`, the architectural check; `kvm_gmem_alloc_file`, which sets up the `gmem_file` and adds it to the list; `__kvm_gmem_create`, which now uses `kvm_gmem_alloc_file`; and finally, the direct entrypoint `kvm_gmem_create`. These are the functions that implement or directly interface with the changes, and are the best symbols to get coverage over. It is important to also note that the static symbols such as `kvm_gmem_alloc_file` and `__kvm_gmem_create` may get inlined, but are listed to ensure coverage is not missed. Next, I needed to figure out the required configurations to reproduce the features and the target symbols. Obviously, `KVM` is necessary, but we also need either `KVM_INTEL` or `KVM_AMD` (or both). Digging through the Kconfig files, `KVM_GUEST_MEMFD` is also selected with `KVM_X86`, so we absolutely need to enable that. I had to make sure the standard VM type supported this functionality. The arch check `kvm_arch_gmem_link_allowed` only compares the VM types, so standard VMs are able to utilize this! In order to test the SW-protected VMs, I'll include `KVM_SW_PROTECTED_VM`. From this, I've got the necessary configs: `KVM`, `KVM_INTEL`, `KVM_AMD`, `KVM_GUEST_MEMFD` and `KVM_SW_PROTECTED_VM`. The symbols that are targetted are `kvm_gmem_link`, `kvm_arch_gmem_link_allowed`, `kvm_gmem_alloc_file`, `kvm_gmem_create` and `__kvm_gmem_create`. The new code introduces new ioctls to handle the features. Overall, this is a prime target for fuzzing. The new ioctl, new reference counting and lifecycle, the shared `guest_memfd` inode and file list, refactored file creation and binding, all add a significant attack surface for race conditions, use-after-free vulnerabilities, and potential memory corruption through invalidation flaws. It's time to set up and let it rip.
32/2	2026/10/26 07:32	tool	set-results	0m Args: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD", "KVM_GUEST_MEMFD", "KVM_SW_PROTECTED_VM" ], "FocusSymbols": [ "kvm_gmem_link", "kvm_arch_gmem_link_allowed", "kvm_gmem_alloc_file", "kvm_gmem_create", "__kvm_gmem_create" ], "Reasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl and the KVM_CAP_GUEST_MEMFD_LINK capability, allowing guest_memfd instances to be linked across different VMs on the host. This refactors guest_memfd file allocation and introduces multi-VM sharing of underlying guest_memfd inodes, adding new concurrency, lifecycle, and memory invalidation interactions between VMs that are accessible from userspace via /dev/kvm.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "KVM", "KVM_INTEL", "KVM_AMD", "KVM_GUEST_MEMFD", "KVM_SW_PROTECTED_VM" ], "FocusSymbols": [ "kvm_gmem_link", "kvm_arch_gmem_link_allowed", "kvm_gmem_alloc_file", "kvm_gmem_create", "__kvm_gmem_create" ], "Reasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl and the KVM_CAP_GUEST_MEMFD_LINK capability, allowing guest_memfd instances to be linked across different VMs on the host. This refactors guest_memfd file allocation and introduces multi-VM sharing of underlying guest_memfd inodes, adding new concurrency, lifecycle, and memory invalidation interactions between VMs that are accessible from userspace via /dev/kvm.", "WorthFuzzing": true }
33/1	2026/10/26 07:32	action	If	1m Args: { "WorthFuzzing": true } Results: null
34/2	2026/10/26 07:32	agent	kmsan-evaluator	1m Model: core Args: null Results: { "KMSANReasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl, enabling an existing guest_memfd file to be linked into a second VM by creating a new struct file sharing the underlying inode.\n\n1. No Info-leaks / User-space Copies: The ioctl takes an input struct kvm_link_guest_memfd copied from user space via copy_from_user() and only returns an integer file descriptor (or negative error code) via the ioctl return value. No kernel structures or data buffers are copied back to user space (no copy_to_user, put_user, or socket/netlink/bpf buffers), so there is no risk of uninitialized struct padding or data leaks.\n2. Initialization of Structs: The newly allocated struct gmem_file is allocated via kzalloc_obj(), which zero-initializes all bytes. Other local stack variables (such as struct timespec64 ts) are written before being read.\n3. Memory / Concurrency Bugs Caught by KASAN/LOCKDEP: Any potential risks introduced by this feature relate to reference counting (fops, inode, kvm instance, and struct file lifetimes), file descriptor management, or locking interactions (e.g., filemap_invalidate_lock), which are detected by KASAN, refcount tracking, and LOCKDEP rather than KMSAN.\n\nTherefore, this patch does not expose uninitialized memory risks, and a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false } Instruction: You are an expert Linux kernel security engineer specializing in kernel memory error detectors (KASAN and KMSAN). Your job is to review the provided patch series and determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer) fuzzing session in addition to standard KASAN fuzzing. CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN: - Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable a comprehensive suite of debugging tools and sanitizers, including KASAN (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks. - KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap, or page allocations) and kernel-to-user memory info-leaks. Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS. A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks that are detected ONLY by KMSAN. Look holistically at the patch series and surrounding code. Even if no direct uninitialized field accesses or new buffer allocations are added in the diff itself, a patch may alter control flow, bounds checking, or data length calculations in ways that change how the rest of the code operates on existing buffers (e.g. allowing uninitialized stack/heap memory to be read, copied to user space, or used in control flow). Do not hesitate to use your code access tools to inspect the surrounding code, called functions, and callers. Set NeedsKMSAN=true ONLY IF the patch introduces or modifies: 1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb attributes, ioctl output arguments, socket options, or BPF buffers) where fields or structure padding might not be fully initialized/zeroed. 2. Conditional logic or branching that depends on potentially uninitialized variables or struct fields. 3. Allocation or initialization of complex data structures where uninitialized fields could be read later in reachable code paths. 4. Bounds checks, lengths, or logic in a way that allows surrounding code to access uninitialized bytes of existing buffers. Set NeedsKMSAN=false IF: - The code changes primarily risk out-of-bounds access, array overflows, NULL pointer dereferences, locking deadlocks, or use-after-free bugs (these are already caught by KASAN, LOCKDEP, or standard bug detectors). - All stack/heap structures touched or introduced by the patch are fully zeroed or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied. - The patch does not introduce any risk of uninitialized memory usage or info-leaks. Use your code access tools to inspect the surrounding code if necessary, then provide detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch. Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit a07cc8d33f8041de7abe39bc5a4e65d36a1c7e23 Author: syz-cluster <triage@syzkaller.com> Date: Mon Oct 26 07:29:57 2026 +0000 syz-cluster: applied patch under review diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 3d6a4bf01c700..bc54212e48c32 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6759,6 +6759,48 @@ if the guest_memfd memory was pinned in IOMMU page tables. See also: :ref:`KVM_SET_MEMORY_ATTRIBUTES`. +4.147 KVM_LINK_GUEST_MEMFD +-------------------------- + +:Capability: KVM_CAP_GUEST_MEMFD_LINK +:Architectures: all +:Type: vm ioctl +:Parameters: struct kvm_link_guest_memfd (in) +:Returns: A file descriptor on success, <0 on error + +Errors: + + ========== =============================================================== + EINVAL ``fd`` is not an open guest_memfd file descriptor, ``flags`` or + ``reserved`` are not zero, the target VM is not compatible with + the VM ``fd`` is associated with (e.g. on x86, the VMs are of + different VM types), or ``fd`` is already associated with the + target VM. + EFAULT The parameter address was invalid. + ENOMEM Ran out of memory. + ========== =============================================================== + +:: + + struct kvm_link_guest_memfd { + __u64 fd; + __u64 flags; + __u64 reserved[6]; + }; + +KVM_LINK_GUEST_MEMFD creates a new guest_memfd file descriptor that is +associated with the target VM (the VM on which the ioctl is invoked) and refers +to the same underlying memory as the existing guest_memfd referred to by ``fd``, +similar to how link() creates another name for an existing file. The new file +descriptor can be used in KVM_SET_USER_MEMORY_REGION2 for the target VM, and +the memory's contents, size, flags and (with in-place conversion) memory +attributes are shared by all linked guest_memfd instances. + +The primary use case is intra-host migration, where the destination VM needs to +access the same guest memory as the source VM without copying it. + +No flags are defined yet; ``flags`` and ``reserved`` must be zero. + .. _kvm_run: 5. The kvm_run structure @@ -9696,6 +9738,14 @@ take care to differentiate between these cases. The presence of this capability indicates that the nested KVM guest can start in ESA mode. +8.48 KVM_CAP_GUEST_MEMFD_LINK +----------------------------- + +:Architectures: all + +The presence of this capability indicates that KVM supports linking an +existing guest_memfd file to another VM via KVM_LINK_GUEST_MEMFD. + 9. Known KVM API problems ========================= diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c081e4b9b25de..4427d32290c0f 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -10648,6 +10648,16 @@ bool kvm_arch_supports_gmem_init_shared(struct kvm kvm) return gmem_in_place_conversion \|\| !kvm_arch_has_private_mem(kvm); } +bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src) +{ + / + * Different VM types have different requirements for, and different + * (vendor) state associated with, guest_memfd memory, e.g. memory that + * is private to a TDX guest must never be mapped into a non-TDX VM. + / + return dst->arch.vm_type == src->arch.vm_type; +} + #ifdef CONFIG_HAVE_KVM_ARCH_GMEM_CONVERT int kvm_arch_gmem_make_private(struct kvm kvm, gfn_t gfn, kvm_pfn_t pfn, kvm_pfn_t nr_pages) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 485f18454eb45..5cffb7ad376e1 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -2585,6 +2585,7 @@ static inline bool kvm_is_private_gfn(struct kvm kvm, gfn_t gfn) #ifdef CONFIG_KVM_GUEST_MEMFD bool kvm_gmem_is_private_gfn(struct kvm kvm, gfn_t gfn); bool kvm_arch_supports_gmem_init_shared(struct kvm kvm); +bool kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src); static inline u64 kvm_gmem_get_supported_flags(struct kvm kvm) { diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 8dff2fc1972e9..09926fa85fe6c 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1000,6 +1000,7 @@ struct kvm_enable_cap { #define KVM_CAP_PPC_COMPAT_CAPS 250 #define KVM_CAP_ARM_PMU_V3_STRICT 251 #define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 252 +#define KVM_CAP_GUEST_MEMFD_LINK 253 struct kvm_irq_routing_irqchip { __u32 irqchip; @@ -1690,4 +1691,12 @@ struct kvm_pre_fault_memory { __u64 padding[5]; }; +#define KVM_LINK_GUEST_MEMFD _IOWR(KVMIO, 0xd6, struct kvm_link_guest_memfd) + +struct kvm_link_guest_memfd { + __u64 fd; + __u64 flags; + __u64 reserved[6]; +}; + #endif /* __LINUX_KVM_H / diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm index 239bc61ea384f..cffa0d165a945 100644 --- a/tools/testing/selftests/kvm/Makefile.kvm +++ b/tools/testing/selftests/kvm/Makefile.kvm @@ -108,6 +108,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_counters_test TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test +TEST_GEN_PROGS_x86 += x86/private_mem_migrate_tests TEST_GEN_PROGS_x86 += x86/save_restore_pf_stress_test TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id TEST_GEN_PROGS_x86 += x86/set_sregs_test diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c b/tools/testing/selftests/kvm/guest_memfd_test.c index 2233d871a38f4..ccde4d735c77c 100644 --- a/tools/testing/selftests/kvm/guest_memfd_test.c +++ b/tools/testing/selftests/kvm/guest_memfd_test.c @@ -418,6 +418,68 @@ static void test_guest_memfd_flags(struct kvm_vm vm) } } +static void test_link(struct kvm_vm vm, int src_fd, size_t total_size) +{ + struct kvm_link_guest_memfd params = {}; + struct stat src_stat, dst_stat; + struct kvm_vm dst_vm; + int dst_fd, bad_fd; + int ret; + + /* guest_memfd can only be linked between VMs of the same type. / + dst_vm = vm_create_barebones_type(vm->type); + + / Linking with an fd that isn't open / + bad_fd = dup(src_fd); + TEST_ASSERT(bad_fd >= 0, "dup() failed"); + close(bad_fd); + ret = __vm_link_guest_memfd(dst_vm, bad_fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with an out-of-range fd, i.e. KVM must not truncate fd / + params.fd = (1ULL << 32) \| src_fd; + ret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, &params); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with a non-gmem fd / + ret = __vm_link_guest_memfd(dst_vm, dst_vm->fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with invalid flags / + ret = __vm_link_guest_memfd(dst_vm, src_fd, 1); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with non-zero reserved fields / + params.fd = src_fd; + params.reserved[5] = 1; + ret = __vm_ioctl(dst_vm, KVM_LINK_GUEST_MEMFD, &params); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + / Linking with an already-associated vm / + ret = __vm_link_guest_memfd(vm, src_fd, 0); + TEST_ASSERT_EQ(ret, -1); + TEST_ASSERT_EQ(errno, EINVAL); + + dst_fd = __vm_link_guest_memfd(dst_vm, src_fd, 0); + TEST_ASSERT(dst_fd >= 0, "linking should succeed with valid inputs"); + TEST_ASSERT(src_fd != dst_fd, "linking should return a different fd"); + + ret = fstat(src_fd, &src_stat); + TEST_ASSERT_EQ(ret, 0); + ret = fstat(dst_fd, &dst_stat); + TEST_ASSERT_EQ(ret, 0); + TEST_ASSERT(src_stat.st_ino == dst_stat.st_ino, + "src and dst files should have the same inode number"); + + close(dst_fd); + kvm_vm_free(dst_vm); +} + #define ____gmem_test(__test, __vm, __flags, __gmem_size, args...) \ do { \ int fd = vm_create_guest_memfd(__vm, __gmem_size, __flags); \ @@ -467,6 +529,8 @@ static void __test_guest_memfd(struct kvm_vm vm, u64 flags) gmem_test(fallocate, vm, flags); gmem_test(invalid_punch_hole, vm, flags); gmem_test_vm(invalid_binding, vm, flags); + if (kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK)) + gmem_test_vm(link, vm, flags); } static void test_guest_memfd(unsigned long vm_type) diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h index 777fa3dbf88d6..f8eca3f7993d0 100644 --- a/tools/testing/selftests/kvm/include/kvm_util.h +++ b/tools/testing/selftests/kvm/include/kvm_util.h @@ -787,6 +787,24 @@ static inline int vm_create_guest_memfd(struct kvm_vm vm, u64 size, return fd; } +static inline int __vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags) +{ + struct kvm_link_guest_memfd params = { + .fd = fd, + .flags = flags, + }; + + return __vm_ioctl(vm, KVM_LINK_GUEST_MEMFD, &params); +} + +static inline int vm_link_guest_memfd(struct kvm_vm vm, int fd, u64 flags) +{ + int new_fd = __vm_link_guest_memfd(vm, fd, flags); + + TEST_ASSERT(new_fd >= 0, KVM_IOCTL_ERROR(KVM_LINK_GUEST_MEMFD, new_fd)); + return new_fd; +} + void vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags, gpa_t gpa, u64 size, void hva); int __vm_set_user_memory_region(struct kvm_vm vm, u32 slot, u32 flags, diff --git a/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c new file mode 100644 index 0000000000000..17bebf850b4c4 --- /dev/null +++ b/tools/testing/selftests/kvm/x86/private_mem_migrate_tests.c @@ -0,0 +1,118 @@ +// SPDX-License-Identifier: GPL-2.0 +#include "kvm_util.h" +#include "test_util.h" +#include "ucall_common.h" +#include <linux/kvm.h> +#include <linux/sizes.h> + +#define TRANSFER_PRIVATE_MEM_TEST_SLOT 10 +#define TRANSFER_PRIVATE_MEM_GPA ((uint64_t)(1ull << 32)) +#define TRANSFER_PRIVATE_MEM_GVA TRANSFER_PRIVATE_MEM_GPA +#define TRANSFER_PRIVATE_MEM_VALUE 0xdeadbeef + +static const struct vm_shape protected_shape = { + .mode = VM_MODE_DEFAULT, + .type = KVM_X86_SW_PROTECTED_VM, +}; + +static void transfer_private_mem_guest_code_src(void) +{ + uint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA; + + WRITE_ONCE(ptr, TRANSFER_PRIVATE_MEM_VALUE); + + GUEST_SYNC1(READ_ONCE(ptr)); +} + +static void transfer_private_mem_guest_code_dst(void) +{ + uint64_t ptr = (uint64_t )TRANSFER_PRIVATE_MEM_GVA; + + GUEST_SYNC1(READ_ONCE(ptr)); +} + +static void add_private_mem(struct kvm_vm vm, int memfd) +{ + vm_mem_add(vm, DEFAULT_VM_MEM_SRC, TRANSFER_PRIVATE_MEM_GPA, + TRANSFER_PRIVATE_MEM_TEST_SLOT, 1, KVM_MEM_GUEST_MEMFD, + memfd, 0, 0); + + virt_map(vm, TRANSFER_PRIVATE_MEM_GVA, TRANSFER_PRIVATE_MEM_GPA, 1); + + /* + * guest_memfd memory is private by default if guest_memfd tracks + * memory attributes, otherwise it must be converted via the VM. + / + if (!kvm_has_gmem_attributes) + vm_mem_set_private(vm, TRANSFER_PRIVATE_MEM_GPA, SZ_4K); +} + +static void test_transfer_private_mem(void) +{ + struct kvm_vm src_vm, dst_vm; + struct kvm_vcpu src_vcpu, dst_vcpu; + int src_memfd, dst_memfd; + struct ucall uc; + + / Build the source VM, use it to write to private memory / + src_vm = __vm_create_shape_with_one_vcpu(protected_shape, &src_vcpu, 0, + transfer_private_mem_guest_code_src); + src_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0); + + add_private_mem(src_vm, src_memfd); + + vcpu_run(src_vcpu); + TEST_ASSERT_KVM_EXIT_REASON(src_vcpu, KVM_EXIT_IO); + get_ucall(src_vcpu, &uc); + TEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE, + "Source VM should be able to write to private memory"); + + / Build the destination VM with linked fd / + dst_vm = __vm_create_shape_with_one_vcpu(protected_shape, &dst_vcpu, 0, + transfer_private_mem_guest_code_dst); + dst_memfd = vm_link_guest_memfd(dst_vm, src_memfd, 0); + + add_private_mem(dst_vm, dst_memfd); + + vcpu_run(dst_vcpu); + TEST_ASSERT_KVM_EXIT_REASON(dst_vcpu, KVM_EXIT_IO); + get_ucall(dst_vcpu, &uc); + TEST_ASSERT(uc.args[0] == TRANSFER_PRIVATE_MEM_VALUE, + "Destination VM should be able to read value transferred"); + + close(dst_memfd); + close(src_memfd); + kvm_vm_free(dst_vm); + kvm_vm_free(src_vm); +} + +static void test_link_different_vm_type(void) +{ + struct kvm_vm src_vm, dst_vm; + int src_memfd, ret; + + src_vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM); + src_memfd = vm_create_guest_memfd(src_vm, SZ_4K, 0); + + dst_vm = vm_create_barebones_type(KVM_X86_DEFAULT_VM); + + ret = __vm_link_guest_memfd(dst_vm, src_memfd, 0); + TEST_ASSERT(ret == -1 && errno == EINVAL, + "Linking into a VM of a different type should fail, ret: %d, errno: %d", + ret, errno); + + close(src_memfd); + kvm_vm_free(dst_vm); + kvm_vm_free(src_vm); +} + +int main(int argc, char argv[]) +{ + TEST_REQUIRE(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM)); + TEST_REQUIRE(kvm_has_cap(KVM_CAP_GUEST_MEMFD_LINK)); + + test_transfer_private_mem(); + test_link_different_vm_type(); + + return 0; +} diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c index 93f3d29d5751a..54b11747a8c48 100644 --- a/virt/kvm/guest_memfd.c +++ b/virt/kvm/guest_memfd.c @@ -892,6 +892,15 @@ bool __weak kvm_arch_supports_gmem_init_shared(struct kvm kvm) return true; } +/ + * Returns true if a guest_memfd instance associated with @src may be linked + * into @dst, i.e. if both VMs can safely share the underlying memory. + / +bool __weak kvm_arch_gmem_link_allowed(struct kvm dst, struct kvm src) +{ + return kvm_arch_has_private_mem(dst) == kvm_arch_has_private_mem(src); +} + static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags) { struct gmem_inode gi = GMEM_I(inode); @@ -937,10 +946,50 @@ static int kvm_gmem_init_inode(struct inode inode, loff_t size, u64 flags) return r; } +/* + * Allocate a new guest_memfd file for @kvm that refers to @inode. On success, + * the returned file takes over the caller's reference to @inode. + / +static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode, + const char name) +{ + struct gmem_file f; + struct file file; + + f = kzalloc_obj(f); + if (!f) + return ERR_PTR(-ENOMEM); + + /* __fput() will take care of fops_put(). / + if (!fops_get(&kvm_gmem_fops)) { + kfree(f); + return ERR_PTR(-ENOENT); + } + + file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops); + if (IS_ERR(file)) { + fops_put(&kvm_gmem_fops); + kfree(f); + return file; + } + + file->f_flags \|= O_LARGEFILE; + file->private_data = f; + + kvm_get_kvm(kvm); + f->kvm = kvm; + xa_init(&f->bindings); + + filemap_invalidate_lock(inode->i_mapping); + list_add(&f->entry, &GMEM_I(inode)->gmem_file_list); + filemap_invalidate_unlock(inode->i_mapping); + + return file; +} + static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags) { static const char name = "[kvm-gmem]"; - struct gmem_file f; struct inode inode; struct file file; int fd, err; @@ -949,51 +998,27 @@ static int __kvm_gmem_create(struct kvm kvm, loff_t size, u64 flags) if (fd < 0) return fd; - f = kzalloc_obj(f); - if (!f) { - err = -ENOMEM; - goto err_fd; - } - - /* __fput() will take care of fops_put(). / - if (!fops_get(&kvm_gmem_fops)) { - err = -ENOENT; - goto err_gmem; - } - inode = anon_inode_make_secure_inode(kvm_gmem_mnt->mnt_sb, name, NULL); if (IS_ERR(inode)) { err = PTR_ERR(inode); - goto err_fops; + goto err_fd; } err = kvm_gmem_init_inode(inode, size, flags); if (err) goto err_inode; - file = alloc_file_pseudo(inode, kvm_gmem_mnt, name, O_RDWR, &kvm_gmem_fops); + file = kvm_gmem_alloc_file(kvm, inode, name); if (IS_ERR(file)) { err = PTR_ERR(file); goto err_inode; } - file->f_flags \|= O_LARGEFILE; - file->private_data = f; - - kvm_get_kvm(kvm); - f->kvm = kvm; - xa_init(&f->bindings); - list_add(&f->entry, &GMEM_I(inode)->gmem_file_list); - fd_install(fd, file); return fd; err_inode: iput(inode); -err_fops: - fops_put(&kvm_gmem_fops); -err_gmem: - kfree(f); err_fd: put_unused_fd(fd); return err; @@ -1013,6 +1038,77 @@ int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args) return __kvm_gmem_create(kvm, size, flags); } +int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args) +{ + static const char name = "[kvm-gmem]"; + u64 flags = args->flags; + u64 valid_flags = 0; + struct file dst_file, src_file; + struct gmem_file gmem; + struct timespec64 ts; + struct inode inode; + struct fd f; + int ret, fd, i; + + if (flags & ~valid_flags) + return -EINVAL; + + for (i = 0; i < ARRAY_SIZE(args->reserved); i++) { + if (args->reserved[i]) + return -EINVAL; + } + + /* Don't let fdget() silently truncate the fd. / + if (args->fd > INT_MAX) + return -EINVAL; + + f = fdget(args->fd); + src_file = fd_file(f); + if (!src_file) + return -EINVAL; + + ret = -EINVAL; + if (src_file->f_op != &kvm_gmem_fops) + goto out; + + / Cannot link a gmem file with the same VM again. / + gmem = src_file->private_data; + if (gmem->kvm == kvm) + goto out; + + if (!kvm_arch_gmem_link_allowed(kvm, gmem->kvm)) + goto out; + + fd = get_unused_fd_flags(0); + if (fd < 0) { + ret = fd; + goto out; + } + + inode = file_inode(src_file); + ihold(inode); + + dst_file = kvm_gmem_alloc_file(kvm, inode, name); + if (IS_ERR(dst_file)) { + iput(inode); + ret = PTR_ERR(dst_file); + goto out_fd; + } + + ts = inode_set_ctime_current(inode); + inode_set_atime_to_ts(inode, ts); + + fd_install(fd, dst_file); + fdput(f); + return fd; + +out_fd: + put_unused_fd(fd); +out: + fdput(f); + return ret; +} + int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot, unsigned int fd, uoff_t offset) { diff --git a/virt/kvm/guest_memfd.h b/virt/kvm/guest_memfd.h index 01bd359d27e30..7ffa4fa7337e9 100644 --- a/virt/kvm/guest_memfd.h +++ b/virt/kvm/guest_memfd.h @@ -8,6 +8,7 @@ int kvm_gmem_init(struct module module); void kvm_gmem_exit(void); int kvm_gmem_create(struct kvm kvm, struct kvm_create_guest_memfd args); +int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args); int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot, unsigned int fd, uoff_t offset); int kvm_gmem_commit_memory_region(struct kvm kvm, struct kvm_memory_slot slot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 3ed481c4a15b6..135e7bb7609a8 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -5008,6 +5008,8 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm kvm, long arg) return 0; return KVM_MEMORY_ATTRIBUTE_PRIVATE; + case KVM_CAP_GUEST_MEMFD_LINK: + return 1; #endif default: break; @@ -5453,6 +5455,16 @@ static long kvm_vm_ioctl(struct file filp, r = kvm_gmem_create(kvm, &guest_memfd); break; } + case KVM_LINK_GUEST_MEMFD: { + struct kvm_link_guest_memfd params; + + r = -EFAULT; + if (copy_from_user(&params, argp, sizeof(params))) + goto out; + + r = kvm_gmem_link(kvm, &params); + break; + } #endif default: r = kvm_arch_vm_ioctl(filp, ioctl, arg);
35/3	2026/10/26 07:32	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 10306 output: 43 thoughts: 885 Thoughts: KMSAN Fuzzing Session Assessment Okay, so I need to decide if this patch series warrants a dedicated KMSAN fuzzing session, or if KASAN is sufficient. The key difference here is KMSAN's focus on detecting uninitialized memory reads and kernel-to-user info-leaks, whereas KASAN covers the usual OOB, UAF, and other standard memory errors. The rule is pretty straightforward: if KASAN can catch it, don't bother with KMSAN. My checklist is clear. I need to look for code that: (1) deals with kernel structures passed to userspace, paying close attention to initialization; (2) involves conditional logic based on potentially uninitialized variables; (3) allocates complex data structures with uninitialized fields; or (4) alters bounds checks in a way that risks uninitialized byte access. This patch series documents a new `KVM_LINK_GUEST_MEMFD` ioctl. Hmm, the documentation says it takes a `struct kvm_link_guest_memfd` as input, which immediately flags my attention. Okay, let's trace the code. The macro `KVM_LINK_GUEST_MEMFD` is defined as `_IOWR`, meaning it's supposed to be both input and output. I need to make sure this is accurate. Digging into `virt/kvm/kvm_main.c`, I see that the kernel only performs `copy_from_user(&params, argp, sizeof(params))` for this structure. Nothing is copied back to userspace! So even though the macro is defined as _IOWR, there's no `copy_to_user` call. The documentation is misleading; there's no information leak risk here. Now, I need to confirm the ioctl function doesn't automatically do anything based on the ioctl direction. I should check `kvm_vm_ioctl` to make sure. I'll use `read-file` or `grepper` to inspect `virt/kvm/kvm_main.c` to be completely certain. So far, this looks like a KASAN-level issue, if anything, but I have a little more work to do to be totally sure.
36/3	2026/10/26 07:32	tool	grepper	0m Args: { "Expression": "case KVM_LINK_GUEST_MEMFD", "PathPrefixes": [ "virt/kvm/kvm_main.c" ] } Results: { "Output": "virt/kvm/kvm_main.c=5227=static long kvm_vm_ioctl(struct file *filp,\n--\nvirt/kvm/kvm_main.c-5457-\t}\nvirt/kvm/kvm_main.c:5458:\tcase KVM_LINK_GUEST_MEMFD: {\nvirt/kvm/kvm_main.c-5459-\t\tstruct kvm_link_guest_memfd params;\n" }
37/3	2026/10/26 07:32	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 11849 output: 40 thoughts: 25 Thoughts: Okay, here's my interpretation of what's going through my mind, delivered as a first-person summary, keeping in mind the audience is an expert: Diving into the KVM Core Alright, I'm heading into `virt/kvm/kvm_main.c` – a familiar spot, though likely a deep dive this time. My objective? Based on the task given, let's target around line 5458. That area is likely involved in... well, it depends. It could be related to interrupt handling, guest memory management, VM creation/destruction, or any number of critical KVM core functions. Given its location in `kvm_main.c`, it's almost guaranteed to be a central piece of the puzzle. I'll need to use my familiarity with the surrounding code to understand the specific context. This means I'll be looking for function calls, data structures that are being manipulated, and any external dependencies. My knowledge of KVM’s architecture will come into play to understand if this is related to something I'm intimately familiar with or if I need to take a step back and examine the surrounding code to contextualize this line. I'll need to figure out what functionality this is actually implementing; if this is something familiar to me, I have a good basis to build upon to understand what is occurring.
38/3	2026/10/26 07:32	tool	read-file	0m Args: { "File": "virt/kvm/kvm_main.c", "FirstLine": 5445, "LineCount": 40 } Results: { "Contents": "5445:\t\t\tr = kvm_vm_ioctl_get_stats_fd(kvm);\n5446:\t\t\tbreak;\n5447:\t#ifdef CONFIG_KVM_GUEST_MEMFD\n5448:\t\tcase KVM_CREATE_GUEST_MEMFD: {\n5449:\t\t\tstruct kvm_create_guest_memfd guest_memfd;\n5450:\t\n5451:\t\t\tr = -EFAULT;\n5452:\t\t\tif (copy_from_user(\u0026guest_memfd, argp, sizeof(guest_memfd)))\n5453:\t\t\t\tgoto out;\n5454:\t\n5455:\t\t\tr = kvm_gmem_create(kvm, \u0026guest_memfd);\n5456:\t\t\tbreak;\n5457:\t\t}\n5458:\t\tcase KVM_LINK_GUEST_MEMFD: {\n5459:\t\t\tstruct kvm_link_guest_memfd params;\n5460:\t\n5461:\t\t\tr = -EFAULT;\n5462:\t\t\tif (copy_from_user(\u0026params, argp, sizeof(params)))\n5463:\t\t\t\tgoto out;\n5464:\t\n5465:\t\t\tr = kvm_gmem_link(kvm, \u0026params);\n5466:\t\t\tbreak;\n5467:\t\t}\n5468:\t#endif\n5469:\t\tdefault:\n5470:\t\t\tr = kvm_arch_vm_ioctl(filp, ioctl, arg);\n5471:\t\t}\n5472:\tout:\n5473:\t\treturn r;\n5474:\t}\n5475:\t\n5476:\t#ifdef CONFIG_KVM_COMPAT\n5477:\tstruct compat_kvm_dirty_log {\n5478:\t\t__u32 slot;\n5479:\t\t__u32 padding1;\n5480:\t\tunion {\n5481:\t\t\tcompat_uptr_t dirty_bitmap; /* one bit per page */\n5482:\t\t\t__u64 padding2;\n5483:\t\t};\n5484:\t};\n" }
39/3	2026/10/26 07:32	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 12767 output: 31 thoughts: 62 Thoughts: Okay, let's dive into this. I need to get a solid understanding of the `guest_memfd` mechanism within KVM. Specifically, I want to trace its execution and understand how the allocation lifecycle works. I need to know how the kernel structures are set up to support it. Dissecting guest_memfd and KVM Memory Allocation I'm thinking, "Where to start?" I'll need to scrutinize how `guest_memfd` actually functions, so I'll need to understand the relationship to `kvm_gmem_alloc_file`. This is crucial. I also want to clarify the purpose and structure of `struct gmem_file`; its design will likely reveal important constraints and capabilities. To get a holistic view, I need to observe how allocations are handled. Ultimately, I'll probably want to know how the memory actually shows up within the guest VM. My focus now is `virt/kvm/guest_memfd.c` – that seems like the central location for this. I'll pore over that file to piece it all together.
40/3	2026/10/26 07:32	tool	grepper	0m Args: { "Expression": "struct gmem_file", "PathPrefixes": [ "virt/kvm/" ] } Results: { "Output": "virt/kvm/guest_memfd.c=16=static struct vfsmount kvm_gmem_mnt;\n--\nvirt/kvm/guest_memfd.c-26- /\nvirt/kvm/guest_memfd.c:27:struct gmem_file {\nvirt/kvm/guest_memfd.c-28-\tstruct kvm kvm;\n--\nvirt/kvm/guest_memfd.c=161=static enum kvm_gfn_range_filter kvm_gmem_get_all_gfns_filter(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-171-\nvirt/kvm/guest_memfd.c:172:static void __kvm_gmem_invalidate_start(struct gmem_file f, pgoff_t start,\nvirt/kvm/guest_memfd.c-173-\t\t\t\t\tpgoff_t end,\n--\nvirt/kvm/guest_memfd.c=213=static void kvm_gmem_invalidate_start(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-216-{\nvirt/kvm/guest_memfd.c:217:\tstruct gmem_file f;\nvirt/kvm/guest_memfd.c-218-\n--\nvirt/kvm/guest_memfd.c-222-\nvirt/kvm/guest_memfd.c:223:static void __kvm_gmem_invalidate_end(struct gmem_file f, pgoff_t start,\nvirt/kvm/guest_memfd.c-224-\t\t\t\t pgoff_t end)\n--\nvirt/kvm/guest_memfd.c=235=static void kvm_gmem_invalidate_end(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-237-{\nvirt/kvm/guest_memfd.c:238:\tstruct gmem_file f;\nvirt/kvm/guest_memfd.c-239-\n--\nvirt/kvm/guest_memfd.c=338=static int kvm_gmem_release(struct inode inode, struct file file)\nvirt/kvm/guest_memfd.c-339-{\nvirt/kvm/guest_memfd.c:340:\tstruct gmem_file f = file-\u003eprivate_data;\nvirt/kvm/guest_memfd.c-341-\tstruct kvm_memory_slot slot;\n--\nvirt/kvm/guest_memfd.c=749=static long kvm_gmem_set_attributes(struct file file, void __user argp)\nvirt/kvm/guest_memfd.c-750-{\nvirt/kvm/guest_memfd.c:751:\tstruct gmem_file f = file-\u003eprivate_data;\nvirt/kvm/guest_memfd.c-752-\tstruct inode inode = file_inode(file);\n--\nvirt/kvm/guest_memfd.c=953=static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode,\n--\nvirt/kvm/guest_memfd.c-955-{\nvirt/kvm/guest_memfd.c:956:\tstruct gmem_file f;\nvirt/kvm/guest_memfd.c-957-\tstruct file file;\n--\nvirt/kvm/guest_memfd.c=1041=int kvm_gmem_link(struct kvm kvm, struct kvm_link_guest_memfd args)\n--\nvirt/kvm/guest_memfd.c-1046-\tstruct file dst_file, src_file;\nvirt/kvm/guest_memfd.c:1047:\tstruct gmem_file gmem;\nvirt/kvm/guest_memfd.c-1048-\tstruct timespec64 ts;\n--\nvirt/kvm/guest_memfd.c=1112=int kvm_gmem_prepare_memory_region(struct kvm kvm, struct kvm_memory_slot slot,\n--\nvirt/kvm/guest_memfd.c-1115-\tuoff_t size = slot-\u003enpages \u003c\u003c PAGE_SHIFT;\nvirt/kvm/guest_memfd.c:1116:\tstruct gmem_file f;\nvirt/kvm/guest_memfd.c-1117-\tstruct inode inode;\n--\nvirt/kvm/guest_memfd.c=1165=int kvm_gmem_commit_memory_region(struct kvm kvm, struct kvm_memory_slot slot)\nvirt/kvm/guest_memfd.c-1166-{\nvirt/kvm/guest_memfd.c:1167:\tstruct gmem_file f = slot-\u003egmem.file-\u003eprivate_data;\nvirt/kvm/guest_memfd.c-1168-\tstruct inode inode = file_inode(slot-\u003egmem.file);\n--\nvirt/kvm/guest_memfd.c=1195=void kvm_gmem_unbind(struct kvm_memory_slot slot)\n--\nvirt/kvm/guest_memfd.c-1199-\tunsigned long end = start + slot-\u003enpages;\nvirt/kvm/guest_memfd.c:1200:\tstruct gmem_file f;\nvirt/kvm/guest_memfd.c-1201-\n--\nvirt/kvm/guest_memfd.c=1234=static struct folio __kvm_gmem_get_pfn(struct file file,\n--\nvirt/kvm/guest_memfd.c-1239-\tstruct file slot_file = READ_ONCE(slot-\u003egmem.file);\nvirt/kvm/guest_memfd.c:1240:\tstruct gmem_file f = file-\u003eprivate_data;\nvirt/kvm/guest_memfd.c-1241-\tstruct folio *folio;\n" }
41/3	2026/10/26 07:32	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 14656 output: 38 thoughts: 28 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person: Diving into `gmem_file` and its Role in Guest Memory Management Alright, let's get down to brass tacks. I need to take a close look at how `struct gmem_file` is defined and, more importantly, how it's actually used within `virt/kvm/guest_memfd.c`. My initial expectation is that this structure is central to managing guest memory backed by memfds, a concept I'm already quite familiar with. I'm assuming this is the core mechanism for KVM's guest memory sharing that leverages memfds. I'll be paying particular attention to the fields within `gmem_file`. I'll be looking for things like reference counts, mappings to host memory, synchronization primitives (mutexes, spinlocks), and any flags or state variables that dictate the lifetime and sharing characteristics of the memfd-backed guest memory. Beyond the structure's definition, I need to understand its operational life cycle: how `gmem_file` instances are created, initialized, and associated with specific guest memory regions. I'll need to follow the code that actually uses these structures to discern the mechanisms involved in allocating, mapping, and unmapping guest memory backed by memfds. I suspect there'll be intricate interactions with the VMM's memory management subsystems and potentially with the hypercall interface. I'll be searching for how the memfd-backed memory is handled when the guest accesses it: is there explicit copying, page faulting, or is it directly mapped? Specifically, I'll be expecting to see a clear delineation of responsibilities: the host's perspective on managing these memfd-backed regions versus the guest's view, and how the interaction between these perspectives is orchestrated. Also, I'll be keeping an eye out for potential performance bottlenecks or subtle race conditions. The synchronization primitives, especially, need to be scrutinized for their effectiveness and potential for contention. I know from experience that memory management can be an area where subtle concurrency issues can lead to some truly perplexing bugs. I'll be keeping a very keen eye on the locking.
42/3	2026/10/26 07:32	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 20, "LineCount": 50 } Results: { "Contents": " 20:\t * \"view\" of the underlying physical memory.\n 21:\t \n 22:\t The gmem's inode is effectively the raw underlying physical storage, and is\n 23:\t * used to track properties of the physical memory, while each gmem file is\n 24:\t * effectively a single VM's view of that storage, and is used to track assets\n 25:\t * specific to its associated VM, e.g. memslots=\u003egmem bindings.\n 26:\t /\n 27:\tstruct gmem_file {\n 28:\t\tstruct kvm kvm;\n 29:\t\tstruct xarray bindings;\n 30:\t\tstruct list_head entry;\n 31:\t};\n 32:\t\n 33:\tstruct gmem_inode {\n 34:\t\tstruct shared_policy policy;\n 35:\t\tstruct inode vfs_inode;\n 36:\t\tstruct list_head gmem_file_list;\n 37:\t\n 38:\t\tu64 flags;\n 39:\t\t/\n 40:\t\t Every index in this inode, whether memory is populated or\n 41:\t\t * not, is tracked in attributes. The entire range of indices,\n 42:\t\t * corresponding to the size of this inode, is represented in\n 43:\t\t * this maple tree.\n 44:\t\t /\n 45:\t\tstruct maple_tree attributes;\n 46:\t};\n 47:\t\n 48:\tstatic __always_inline struct gmem_inode GMEM_I(struct inode inode)\n 49:\t{\n 50:\t\treturn container_of(inode, struct gmem_inode, vfs_inode);\n 51:\t}\n 52:\t\n 53:\t#define kvm_gmem_for_each_file(f, inode) \\\n 54:\t\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\n 55:\t\n 56:\t/\n 57:\t folio_file_pfn - like folio_file_page, but return a pfn.\n 58:\t * @folio: The folio which contains this index.\n 59:\t * @index: The index we want to look up.\n 60:\t \n 61:\t Return: The pfn for this index.\n 62:\t /\n 63:\tstatic inline kvm_pfn_t folio_file_pfn(struct folio folio, pgoff_t index)\n 64:\t{\n 65:\t\treturn folio_pfn(folio) + (index \u0026 (folio_nr_pages(folio) - 1));\n 66:\t}\n 67:\t\n 68:\tstatic pgoff_t kvm_gmem_get_index(struct kvm_memory_slot *slot, gfn_t gfn)\n 69:\t{\n" }
43/3	2026/10/26 07:32	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 15929 output: 38 thoughts: 1889 Thoughts: Analyzing KVM's Guest Memory File Descriptors Okay, let's break this down systematically. I'm looking at `kvm_gmem_alloc_file`, and it's immediately clear this is the key function for creating these guest memory file descriptors. It allocates a `gmem_file` structure using `kzalloc_obj`, which zeros out all of the memory. Good. It then acquires a reference to the `kvm_gmem_fops` structure. The function then allocates a pseudo file using `alloc_file_pseudo`, and importantly, this function copies the file operations into the newly allocated file. It appears the virtual file system has been set up with this file. It sets `O_LARGEFILE` flag and stores the `gmem_file` as private data, which is standard practice. We increment the KVM reference count and initialize the XArray, and add it to a list. Crucially, before the patch, the code was missing a lock around the list add! This means that if an inode was already created, the list add wasn't protected by a file mapping invalidate lock. Now, let's consider the creation process with `__kvm_gmem_create`. It allocates an anonymous inode, initializes it, and calls `kvm_gmem_alloc_file`. It then installs the file descriptor. Now, let's analyze `kvm_gmem_link`. This is where it gets interesting, as it creates a link to an existing guest memory file descriptor. It checks for invalid flags in `args->flags`, and the `args->reserved` fields. It then retrieves the file using `fdget` and verifies that the file operations match. It also checks that we are not attempting to link a guest memory file to the same VM, and that the link is allowed by `kvm_arch_gmem_link_allowed`. It then allocates a new file descriptor with `get_unused_fd_flags` and duplicates the inode of the source file. It then calls `kvm_gmem_alloc_file` on the inode, increments the inode’s reference count with `ihold`, then links the new file descriptor to the new gmem file, calls `fd_install` and finally `fdput`. The inode's access and modification times are updated with current time. The existing file and the newly linked one now share the same memory. What's important is the return value of `kvm_gmem_link`. It returns an `fd`, which is returned to userspace via `ioctl`. Checking the ioctl code, `KVM_LINK_GUEST_MEMFD`, and its associated data copying, the kernel reads from user space, with `copy_from_user` to the `struct kvm_link_guest_memfd params`. However, the kernel doesn't copy anything back to userspace, which is as expected, since `KVM_LINK_GUEST_MEMFD` is an input parameter according to `api.rst`. Therefore, KVM doesn't implicitly copy based on the definition as `_IOWR`, but the explicit call to copy_from_user does happen. So, the next obvious question: what is the memory layout for `guest_memfd`? Does this allow us to read uninitialized memory? I need to dig into how the underlying memory is allocated, read, converted, and mapped within `virt/kvm/guest_memfd.c` to identify any potential security implications or memory exposure issues. I have a hunch that there may be some subtlety there, potentially around memory initialization or the sharing of memory regions between VMs and uninitialized state, and I'll need to confirm that.
44/3	2026/10/26 07:33	tool	grepper	0m Args: { "Expression": "kvm_gmem_", "PathPrefixes": [ "virt/kvm/guest_memfd.c" ] } Results: { "Output": "\nFull output is too long, showing 200 out of 567 lines.\nUse more precise expression or PathPrefixes if possible.\n\nNumber of matching lines per file (1 files in total):\nvirt/kvm/guest_memfd.c:172\n\nvirt/kvm/guest_memfd.c-15-\nvirt/kvm/guest_memfd.c:16:static struct vfsmount kvm_gmem_mnt;\nvirt/kvm/guest_memfd.c-17-\n--\nvirt/kvm/guest_memfd.c=48=static __always_inline struct gmem_inode GMEM_I(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-52-\nvirt/kvm/guest_memfd.c:53:#define kvm_gmem_for_each_file(f, inode) \\\nvirt/kvm/guest_memfd.c-54-\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\n--\nvirt/kvm/guest_memfd.c=63=static inline kvm_pfn_t folio_file_pfn(struct folio folio, pgoff_t index)\n--\nvirt/kvm/guest_memfd.c-67-\nvirt/kvm/guest_memfd.c:68:static pgoff_t kvm_gmem_get_index(struct kvm_memory_slot slot, gfn_t gfn)\nvirt/kvm/guest_memfd.c-69-{\n--\nvirt/kvm/guest_memfd.c-72-\nvirt/kvm/guest_memfd.c:73:static u64 kvm_gmem_get_default_attributes(struct inode inode)\nvirt/kvm/guest_memfd.c-74-{\n--\nvirt/kvm/guest_memfd.c-79-\nvirt/kvm/guest_memfd.c:80:static u64 kvm_gmem_get_attributes(struct inode inode, void entry)\nvirt/kvm/guest_memfd.c-81-{\nvirt/kvm/guest_memfd.c-82-\tif (WARN_ON_ONCE(!entry))\nvirt/kvm/guest_memfd.c:83:\t\treturn kvm_gmem_get_default_attributes(inode);\nvirt/kvm/guest_memfd.c-84-\n--\nvirt/kvm/guest_memfd.c-87-\nvirt/kvm/guest_memfd.c:88:static bool kvm_gmem_is_private_mem(struct inode inode, pgoff_t index)\nvirt/kvm/guest_memfd.c-89-{\n--\nvirt/kvm/guest_memfd.c-92-\nvirt/kvm/guest_memfd.c:93:\treturn kvm_gmem_get_attributes(inode, entry) \u0026\nvirt/kvm/guest_memfd.c-94-\t KVM_MEMORY_ATTRIBUTE_PRIVATE;\n--\nvirt/kvm/guest_memfd.c-96-\nvirt/kvm/guest_memfd.c:97:static bool kvm_gmem_is_shared_mem(struct inode inode, pgoff_t index)\nvirt/kvm/guest_memfd.c-98-{\nvirt/kvm/guest_memfd.c:99:\treturn !kvm_gmem_is_private_mem(inode, index);\nvirt/kvm/guest_memfd.c-100-}\nvirt/kvm/guest_memfd.c-101-\nvirt/kvm/guest_memfd.c:102:static bool kvm_gmem_range_has_attributes(struct inode inode,\nvirt/kvm/guest_memfd.c-103-\t\t\t\t\t pgoff_t index, size_t nr_pages,\n--\nvirt/kvm/guest_memfd.c-112-\tmt_for_each(mt, entry, index, end) {\nvirt/kvm/guest_memfd.c:113:\t\tif (kvm_gmem_get_attributes(inode, entry) != attributes)\nvirt/kvm/guest_memfd.c-114-\t\t\treturn false;\n--\nvirt/kvm/guest_memfd.c-128- /\nvirt/kvm/guest_memfd.c:129:static struct folio kvm_gmem_get_folio(struct inode inode, pgoff_t index)\nvirt/kvm/guest_memfd.c-130-{\n--\nvirt/kvm/guest_memfd.c-149-\t/\nvirt/kvm/guest_memfd.c:150:\t External interfaces like kvm_gmem_get_pfn() support dealing\nvirt/kvm/guest_memfd.c-151-\t * with hugepages to a degree, but internally, guest_memfd currently\n--\nvirt/kvm/guest_memfd.c-160-\nvirt/kvm/guest_memfd.c:161:static enum kvm_gfn_range_filter kvm_gmem_get_all_gfns_filter(struct inode inode)\nvirt/kvm/guest_memfd.c-162-{\n--\nvirt/kvm/guest_memfd.c-171-\nvirt/kvm/guest_memfd.c:172:static void __kvm_gmem_invalidate_start(struct gmem_file f, pgoff_t start,\nvirt/kvm/guest_memfd.c-173-\t\t\t\t\tpgoff_t end,\n--\nvirt/kvm/guest_memfd.c-212-\nvirt/kvm/guest_memfd.c:213:static void kvm_gmem_invalidate_start(struct inode inode, pgoff_t start,\nvirt/kvm/guest_memfd.c-214-\t\t\t\t pgoff_t end,\n--\nvirt/kvm/guest_memfd.c-218-\nvirt/kvm/guest_memfd.c:219:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c:220:\t\t__kvm_gmem_invalidate_start(f, start, end, filter);\nvirt/kvm/guest_memfd.c-221-}\nvirt/kvm/guest_memfd.c-222-\nvirt/kvm/guest_memfd.c:223:static void __kvm_gmem_invalidate_end(struct gmem_file f, pgoff_t start,\nvirt/kvm/guest_memfd.c-224-\t\t\t\t pgoff_t end)\n--\nvirt/kvm/guest_memfd.c-234-\nvirt/kvm/guest_memfd.c:235:static void kvm_gmem_invalidate_end(struct inode inode, pgoff_t start,\nvirt/kvm/guest_memfd.c-236-\t\t\t\t pgoff_t end)\n--\nvirt/kvm/guest_memfd.c-239-\nvirt/kvm/guest_memfd.c:240:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c:241:\t\t__kvm_gmem_invalidate_end(f, start, end);\nvirt/kvm/guest_memfd.c-242-}\nvirt/kvm/guest_memfd.c-243-\nvirt/kvm/guest_memfd.c:244:static long kvm_gmem_punch_hole(struct inode inode, loff_t offset, loff_t len)\nvirt/kvm/guest_memfd.c-245-{\nvirt/kvm/guest_memfd.c:246:\tenum kvm_gfn_range_filter filter = kvm_gmem_get_all_gfns_filter(inode);\nvirt/kvm/guest_memfd.c-247-\tpgoff_t start = offset \u003e\u003e PAGE_SHIFT;\n--\nvirt/kvm/guest_memfd.c-255-\nvirt/kvm/guest_memfd.c:256:\tkvm_gmem_invalidate_start(inode, start, end, filter);\nvirt/kvm/guest_memfd.c-257-\n--\nvirt/kvm/guest_memfd.c-259-\nvirt/kvm/guest_memfd.c:260:\tkvm_gmem_invalidate_end(inode, start, end);\nvirt/kvm/guest_memfd.c-261-\n--\nvirt/kvm/guest_memfd.c-266-\nvirt/kvm/guest_memfd.c:267:static long kvm_gmem_allocate(struct inode inode, loff_t offset, loff_t len)\nvirt/kvm/guest_memfd.c-268-{\n--\nvirt/kvm/guest_memfd.c-290-\nvirt/kvm/guest_memfd.c:291:\t\tfolio = kvm_gmem_get_folio(inode, index);\nvirt/kvm/guest_memfd.c-292-\t\tif (IS_ERR(folio)) {\n--\nvirt/kvm/guest_memfd.c-313-\nvirt/kvm/guest_memfd.c:314:static long kvm_gmem_fallocate(struct file file, int mode, loff_t offset,\nvirt/kvm/guest_memfd.c-315-\t\t\t loff_t len)\n--\nvirt/kvm/guest_memfd.c-328-\tif (mode \u0026 FALLOC_FL_PUNCH_HOLE)\nvirt/kvm/guest_memfd.c:329:\t\tret = kvm_gmem_punch_hole(file_inode(file), offset, len);\nvirt/kvm/guest_memfd.c-330-\telse\nvirt/kvm/guest_memfd.c:331:\t\tret = kvm_gmem_allocate(file_inode(file), offset, len);\nvirt/kvm/guest_memfd.c-332-\n--\nvirt/kvm/guest_memfd.c-337-\nvirt/kvm/guest_memfd.c:338:static int kvm_gmem_release(struct inode inode, struct file file)\nvirt/kvm/guest_memfd.c-339-{\n--\nvirt/kvm/guest_memfd.c-349-\t * against memslot updates, specifically so that unbind doesn't race\nvirt/kvm/guest_memfd.c:350:\t * and free the memslot (kvm_gmem_get_file() will return NULL).\nvirt/kvm/guest_memfd.c-351-\t /\n--\nvirt/kvm/guest_memfd.c-360-\t synchronize_srcu_expedited() in kvm_swap_active_memslots() to ensure\nvirt/kvm/guest_memfd.c:361:\t * kvm_gmem_get_pfn() (which runs with kvm-\u003esrcu held for read) can't\nvirt/kvm/guest_memfd.c-362-\t * grab a reference to slot-\u003egmem.file even if the struct file object\n--\nvirt/kvm/guest_memfd.c-365-\t * file_ref_put() provides a full barrier, and __get_file_rcu() the\nvirt/kvm/guest_memfd.c:366:\t * matching acquire barrier, to ensure that kvm_gmem_get_file() (via\nvirt/kvm/guest_memfd.c-367-\t * __get_file_rcu()) sees refcount==0 or fails the \"file reloaded\"\n--\nvirt/kvm/guest_memfd.c-371-\t * if they race with a write, only that they have a reference to _a_\nvirt/kvm/guest_memfd.c:372:\t * live file, kvm_gmem_get_pfn() needs to get the exact file that is\nvirt/kvm/guest_memfd.c-373-\t * associated with the memslot. Without the aforementioned SRCU\n--\nvirt/kvm/guest_memfd.c-376-\t * CPU0\t\t\t\tCPU1\nvirt/kvm/guest_memfd.c:377:\t * kvm_gmem_get_pfn()\nvirt/kvm/guest_memfd.c-378-\t * slot-\u003egmem.file == A\nvirt/kvm/guest_memfd.c:379:\t \t\t\t\t\tkvm_gmem_release())\nvirt/kvm/guest_memfd.c-380-\t \t\t\t\t\t slot-\u003egmem.file = NULL\n--\nvirt/kvm/guest_memfd.c-408-\t /\nvirt/kvm/guest_memfd.c:409:\t__kvm_gmem_invalidate_start(f, 0, -1ul,\nvirt/kvm/guest_memfd.c:410:\t\t\t\t kvm_gmem_get_all_gfns_filter(inode));\nvirt/kvm/guest_memfd.c:411:\t__kvm_gmem_invalidate_end(f, 0, -1ul);\nvirt/kvm/guest_memfd.c-412-\n--\nvirt/kvm/guest_memfd.c-426-\nvirt/kvm/guest_memfd.c:427:static inline struct file kvm_gmem_get_file(struct kvm_memory_slot slot)\nvirt/kvm/guest_memfd.c-428-{\n--\nvirt/kvm/guest_memfd.c-431-\t there might be some time between the last fput() and when\nvirt/kvm/guest_memfd.c:432:\t * kvm_gmem_release() clears slot-\u003egmem.file.\nvirt/kvm/guest_memfd.c-433-\t /\n--\nvirt/kvm/guest_memfd.c=437=DEFINE_CLASS(gmem_get_file, struct file , if (_T) fput(_T),\nvirt/kvm/guest_memfd.c:438:\t kvm_gmem_get_file(slot), struct kvm_memory_slot slot);\nvirt/kvm/guest_memfd.c-439-\nvirt/kvm/guest_memfd.c:440:static bool kvm_gmem_supports_mmap(struct inode inode)\nvirt/kvm/guest_memfd.c-441-{\n--\nvirt/kvm/guest_memfd.c-444-\nvirt/kvm/guest_memfd.c:445:static vm_fault_t kvm_gmem_fault_user_mapping(struct vm_fault vmf)\nvirt/kvm/guest_memfd.c-446-{\n--\nvirt/kvm/guest_memfd.c-454-\tfilemap_invalidate_lock_shared(inode-\u003ei_mapping);\nvirt/kvm/guest_memfd.c:455:\tif (kvm_gmem_is_shared_mem(inode, vmf-\u003epgoff))\nvirt/kvm/guest_memfd.c:456:\t\tfolio = kvm_gmem_get_folio(inode, vmf-\u003epgoff);\nvirt/kvm/guest_memfd.c-457-\telse\n--\nvirt/kvm/guest_memfd.c-489-#ifdef CONFIG_NUMA\nvirt/kvm/guest_memfd.c:490:static int kvm_gmem_set_policy(struct vm_area_struct vma, struct mempolicy mpol)\nvirt/kvm/guest_memfd.c-491-{\n--\nvirt/kvm/guest_memfd.c-496-\nvirt/kvm/guest_memfd.c:497:static struct mempolicy kvm_gmem_get_policy(struct vm_area_struct vma,\nvirt/kvm/guest_memfd.c-498-\t\t\t\t\t unsigned long addr, pgoff_t ilx)\n--\nvirt/kvm/guest_memfd.c-517-\nvirt/kvm/guest_memfd.c:518:static const struct vm_operations_struct kvm_gmem_vm_ops = {\nvirt/kvm/guest_memfd.c:519:\t.fault\t\t= kvm_gmem_fault_user_mapping,\nvirt/kvm/guest_memfd.c-520-#ifdef CONFIG_NUMA\nvirt/kvm/guest_memfd.c:521:\t.get_policy\t= kvm_gmem_get_policy,\nvirt/kvm/guest_memfd.c:522:\t.set_policy\t= kvm_gmem_set_policy,\nvirt/kvm/guest_memfd.c-523-#endif\n--\nvirt/kvm/guest_memfd.c-525-\nvirt/kvm/guest_memfd.c:526:static int kvm_gmem_mmap(struct file file, struct vm_area_struct vma)\nvirt/kvm/guest_memfd.c-527-{\nvirt/kvm/guest_memfd.c:528:\tif (!kvm_gmem_supports_mmap(file_inode(file)))\nvirt/kvm/guest_memfd.c-529-\t\treturn -ENODEV;\n--\nvirt/kvm/guest_memfd.c-535-\nvirt/kvm/guest_memfd.c:536:\tvma-\u003evm_ops = \u0026kvm_gmem_vm_ops;\nvirt/kvm/guest_memfd.c-537-\n--\nvirt/kvm/guest_memfd.c-540-\nvirt/kvm/guest_memfd.c:541:bool kvm_gmem_is_private_gfn(struct kvm *kvm, gfn_t gfn)\nvirt/kvm/guest_memfd.c-542-{\n\n" }
45/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 23252 output: 39 thoughts: 57 Thoughts: Here's my understanding of the memory allocation process, based on the `guest_memfd` code: Analyzing Guest Memory Allocation via Memfd Okay, so I need to dig into how guest memory, specifically through the `memfd` mechanism, is being handled. I need to understand how the memory is actually allocated in that context. My immediate focus is on the `kvm_gmem_get_folio(inode, index)` function. That function will likely be the key to tracing the actual allocation flow. I'll start by taking a look at lines 125-160 of `virt/kvm/guest_memfd.c` because that function will be the starting point to understand this process and that code section likely contains the details I'm looking for. This will give me the building blocks I need to create a complete understanding. From there, I'll assess the implications on performance and security.
46/3	2026/10/26 07:33	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 125, "LineCount": 35 } Results: { "Contents": " 125:\t \n 126:\t Ignore accessed, referenced, and dirty flags. The memory is\n 127:\t * unevictable and there is no storage to write back to.\n 128:\t /\n 129:\tstatic struct folio kvm_gmem_get_folio(struct inode inode, pgoff_t index)\n 130:\t{\n 131:\t\t/ TODO: Support huge pages. /\n 132:\t\tstruct mempolicy policy;\n 133:\t\tstruct folio folio;\n 134:\t\n 135:\t\t/\n 136:\t\t * Fast-path: See if folio is already present in mapping to avoid\n 137:\t\t * policy_lookup.\n 138:\t\t /\n 139:\t\tfolio = filemap_lock_folio(inode-\u003ei_mapping, index);\n 140:\t\tif (!IS_ERR(folio))\n 141:\t\t\treturn folio;\n 142:\t\n 143:\t\tpolicy = mpol_shared_policy_lookup(\u0026GMEM_I(inode)-\u003epolicy, index);\n 144:\t\tfolio = __filemap_get_folio_mpol(inode-\u003ei_mapping, index,\n 145:\t\t\t\t\t\t FGP_LOCK \| FGP_CREAT,\n 146:\t\t\t\t\t\t mapping_gfp_mask(inode-\u003ei_mapping), policy);\n 147:\t\tmpol_cond_put(policy);\n 148:\t\n 149:\t\t/\n 150:\t\t * External interfaces like kvm_gmem_get_pfn() support dealing\n 151:\t\t * with hugepages to a degree, but internally, guest_memfd currently\n 152:\t\t * assumes that all folios are order-0 and handling would need\n 153:\t\t * to be updated for anything otherwise (e.g. page-clearing\n 154:\t\t * operations).\n 155:\t\t */\n 156:\t\tWARN_ON_ONCE(!IS_ERR(folio) \u0026\u0026 folio_order(folio));\n 157:\t\n 158:\t\treturn folio;\n 159:\t}\n" }
47/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 24101 output: 39 thoughts: 32 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person: Initial Folio Initialization: A Deep Dive Alright, so I'm thinking about how folios are actually brought to life when they're first created, and the key question is how the kernel handles the initial setup. My mind immediately goes to the potential use of `kvm_gmem_init_inode`, or maybe the interplay with `mapping_gfp_mask`. I need to recall the specifics of these functions and their relationships, because they have a bearing on the performance of the whole system. Let me delve deeper to analyze the relevant data structures. What does the initialization procedure look like? Are we talking about zeroing pages, setting up initial metadata, or a combination of operations? The details here are critical for understanding any potential optimization points, especially under high load when we create multiple folios. Understanding these initialization steps is a fundamental building block.
48/3	2026/10/26 07:33	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 910, "LineCount": 40 } Results: { "Contents": " 910:\t\n 911:\t\tinode-\u003ei_op = \u0026kvm_gmem_iops;\n 912:\t\tinode-\u003ei_mapping-\u003ea_ops = \u0026kvm_gmem_aops;\n 913:\t\tinode-\u003ei_mode \|= S_IFREG;\n 914:\t\tinode-\u003ei_size = size;\n 915:\t\tmapping_set_gfp_mask(inode-\u003ei_mapping, GFP_HIGHUSER);\n 916:\t\n 917:\t\t/\n 918:\t\t guest_memfd memory is neither migratable nor swappable: set\n 919:\t\t * inaccessible to gate off both.\n 920:\t\t /\n 921:\t\tmapping_set_inaccessible(inode-\u003ei_mapping);\n 922:\t\tWARN_ON_ONCE(!mapping_unevictable(inode-\u003ei_mapping));\n 923:\t\n 924:\t\tgi-\u003eflags = flags;\n 925:\t\n 926:\t\tmt_set_external_lock(\u0026gi-\u003eattributes,\n 927:\t\t\t\t \u0026inode-\u003ei_mapping-\u003einvalidate_lock);\n 928:\t\n 929:\t\t/\n 930:\t\t * Store default attributes for the entire gmem instance. Ensuring every\n 931:\t\t * index is represented in the maple tree at all times simplifies the\n 932:\t\t * conversion and merging logic.\n 933:\t\t /\n 934:\t\tattrs = kvm_gmem_get_default_attributes(inode);\n 935:\t\n 936:\t\t/\n 937:\t\t * Acquire the invalidation lock purely to make lockdep happy. The\n 938:\t\t * maple tree library expects all stores to be protected via the lock,\n 939:\t\t * and the library can't know when the tree is reachable only by the\n 940:\t\t * caller, as is the case here.\n 941:\t\t /\n 942:\t\tfilemap_invalidate_lock(inode-\u003ei_mapping);\n 943:\t\tr = mas_store_gfp(\u0026mas, xa_mk_value(attrs), GFP_KERNEL);\n 944:\t\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n 945:\t\n 946:\t\treturn r;\n 947:\t}\n 948:\t\n 949:\t/\n" }
49/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 24990 output: 38 thoughts: 1200 Thoughts: Analyzing the Security Implications of `kvm_gmem_link` Okay, let's dissect this `kvm_gmem_link` function and the surrounding code, focusing on potential security vulnerabilities. My first thought is to ensure the code's behavior aligns with its intent, and it doesn't open any unforeseen attack vectors. First, I examined the `kvm_main.c` part, focusing on the `KVM_LINK_GUEST_MEMFD` ioctl. It seems like the critical structure `params` is transferred via `copy_from_user` and isn't sent back. That is good from a security perspective. It is good that the return value is just the `fd` or an error code. I'll need to double-check that this `fd` is properly handled. Now, scrutinizing `kvm_gmem_link` itself, I noticed the important checks: the `flags` and `reserved` fields are sanity-checked. The `fd` value is range-checked against `INT_MAX`, and the file operation pointer is carefully verified. The check to make sure the same `gmem` isn't linked to the same VM again is also a sensible precaution. Moreover, `kvm_arch_gmem_link_allowed` is there for architecture-specific restrictions. The `get_unused_fd_flags` call and the subsequent inode holding seem standard. The core of the logic resides in `kvm_gmem_alloc_file`. Here, I'm pleased to see that `kzalloc_obj` is used for initialization. This effectively zeros out the allocated `f` structure, which mitigates any risk of uninitialized memory exposure. I noted that `xa_init` is called on `f->bindings`. The structure initialization is a key point, and the use of zeroing allocation is reassuring. Moving on, I need to look for any information that's being passed back to the user space. It seems there are no calls to `copy_to_user`, no netlink messages, no socket options, and no BPF-related code. That's excellent; this means that there's no direct exposure of kernel memory to userspace through this path. Finally, the question I need to answer is if there is any control flow or use of length information that may cause an uninitialized memory read. The focus is to check how multiple files may interact with the `gmem_inode`. Now I must check where `gmem_file_list` is used.
50/3	2026/10/26 07:33	tool	grepper	0m Args: { "Expression": "gmem_file_list", "PathPrefixes": [ "virt/kvm/guest_memfd.c" ] } Results: { "Output": "virt/kvm/guest_memfd.c=33=struct gmem_inode {\n--\nvirt/kvm/guest_memfd.c-35-\tstruct inode vfs_inode;\nvirt/kvm/guest_memfd.c:36:\tstruct list_head gmem_file_list;\nvirt/kvm/guest_memfd.c-37-\n--\nvirt/kvm/guest_memfd.c=48=static __always_inline struct gmem_inode GMEM_I(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-53-#define kvm_gmem_for_each_file(f, inode) \\\nvirt/kvm/guest_memfd.c:54:\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\nvirt/kvm/guest_memfd.c-55-\n--\nvirt/kvm/guest_memfd.c=953=static struct file kvm_gmem_alloc_file(struct kvm kvm, struct inode inode,\n--\nvirt/kvm/guest_memfd.c-983-\tfilemap_invalidate_lock(inode-\u003ei_mapping);\nvirt/kvm/guest_memfd.c:984:\tlist_add(\u0026f-\u003eentry, \u0026GMEM_I(inode)-\u003egmem_file_list);\nvirt/kvm/guest_memfd.c-985-\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n--\nvirt/kvm/guest_memfd.c=1423=static struct inode kvm_gmem_alloc_inode(struct super_block *sb)\n--\nvirt/kvm/guest_memfd.c-1442-\tgi-\u003eflags = 0;\nvirt/kvm/guest_memfd.c:1443:\tINIT_LIST_HEAD(\u0026gi-\u003egmem_file_list);\nvirt/kvm/guest_memfd.c-1444-\treturn \u0026gi-\u003evfs_inode;\n" }
51/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 27288 output: 43 thoughts: 113 Thoughts: Invalidation with `kvm_gmem_for_each_file` Okay, so I'm focusing on invalidation, and it looks like `kvm_gmem_for_each_file` is the key function being used. I need to understand its role better. Right, I remember seeing it earlier in `kvm_gmem_invalidate_start` and `kvm_gmem_invalidate_end`. Both of those functions clearly involve looping over the results of `kvm_gmem_for_each_file`. My next step is to make sure those are the only places this function is being called. I need to exhaustively check for any other usages. Knowing where this is used will give me a better understanding of the overall invalidation process.
52/3	2026/10/26 07:33	tool	grepper	0m Args: { "Expression": "kvm_gmem_for_each_file", "PathPrefixes": [ "virt/kvm/guest_memfd.c" ] } Results: { "Output": "virt/kvm/guest_memfd.c=48=static __always_inline struct gmem_inode GMEM_I(struct inode inode)\n--\nvirt/kvm/guest_memfd.c-52-\nvirt/kvm/guest_memfd.c:53:#define kvm_gmem_for_each_file(f, inode) \\\nvirt/kvm/guest_memfd.c-54-\tlist_for_each_entry(f, \u0026GMEM_I(inode)-\u003egmem_file_list, entry)\n--\nvirt/kvm/guest_memfd.c=213=static void kvm_gmem_invalidate_start(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-218-\nvirt/kvm/guest_memfd.c:219:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c-220-\t\t__kvm_gmem_invalidate_start(f, start, end, filter);\n--\nvirt/kvm/guest_memfd.c=235=static void kvm_gmem_invalidate_end(struct inode inode, pgoff_t start,\n--\nvirt/kvm/guest_memfd.c-239-\nvirt/kvm/guest_memfd.c:240:\tkvm_gmem_for_each_file(f, inode)\nvirt/kvm/guest_memfd.c-241-\t\t__kvm_gmem_invalidate_end(f, start, end);\n" }
53/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 28020 output: 39 thoughts: 24 Thoughts: Okay, here's my take on those thoughts, tailored for an expert audience, presented in the first person: Investigating the Release Mechanism for `gmem_file` within `kvm_gmem_release` Alright, let's dive into this. I'm focusing on how `gmem_file`'s release is handled within the `kvm_gmem_release` function. My initial question is pretty straightforward: what's the control flow here? I need to understand the specifics of how this particular `gmem_file` is cleaned up. I want to know about any critical locking primitives involved, any potential resource leaks that are avoided, and generally, the efficiency of the deallocation strategy. My understanding of the surrounding KVM code is solid, so I'm thinking about the low-level details of memory management, likely referencing my mental model of the relevant kernel structures. I'm probably mentally parsing through the code and looking for any potential synchronization issues or race conditions that could lead to errors. I am focusing on what may need to be handled here because I'm reviewing the implementation.
54/3	2026/10/26 07:33	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 338, "LineCount": 50 } Results: { "Contents": " 338:\tstatic int kvm_gmem_release(struct inode inode, struct file file)\n 339:\t{\n 340:\t\tstruct gmem_file f = file-\u003eprivate_data;\n 341:\t\tstruct kvm_memory_slot slot;\n 342:\t\tstruct kvm kvm = f-\u003ekvm;\n 343:\t\tunsigned long index;\n 344:\t\n 345:\t\t/\n 346:\t\t * Prevent concurrent attempts to unbind a memslot. This is the last\n 347:\t\t * reference to the file and thus no new bindings can be created, but\n 348:\t\t * dereferencing the slot for existing bindings needs to be protected\n 349:\t\t * against memslot updates, specifically so that unbind doesn't race\n 350:\t\t * and free the memslot (kvm_gmem_get_file() will return NULL).\n 351:\t\t /\n 352:\t\tmutex_lock(\u0026kvm-\u003eslots_lock);\n 353:\t\n 354:\t\tfilemap_invalidate_lock(inode-\u003ei_mapping);\n 355:\t\n 356:\t\t/\n 357:\t\t * Note! synchronize_srcu() is _not_ needed after nullifying memslot\n 358:\t\t * bindings as slot-\u003egmem.file cannot be set back to a non-null value\n 359:\t\t * without the memslot first being deleted. I.e. this relies on the\n 360:\t\t * synchronize_srcu_expedited() in kvm_swap_active_memslots() to ensure\n 361:\t\t * kvm_gmem_get_pfn() (which runs with kvm-\u003esrcu held for read) can't\n 362:\t\t * grab a reference to slot-\u003egmem.file even if the struct file object\n 363:\t\t * is reallocated (for use as a different file).\n 364:\t\t \n 365:\t\t file_ref_put() provides a full barrier, and __get_file_rcu() the\n 366:\t\t * matching acquire barrier, to ensure that kvm_gmem_get_file() (via\n 367:\t\t * __get_file_rcu()) sees refcount==0 or fails the \"file reloaded\"\n 368:\t\t * check (file != NULL due to nullifying the file pointer here).\n 369:\t\t \n 370:\t\t Unlike most other users of get_file_rcu(), where callers don't care\n 371:\t\t * if they race with a write, only that they have a reference to _a_\n 372:\t\t * live file, kvm_gmem_get_pfn() needs to get the exact file that is\n 373:\t\t * associated with the memslot. Without the aforementioned SRCU\n 374:\t\t * synchronization, the following could happen:\n 375:\t\t \n 376:\t\t CPU0\t\t\t\tCPU1\n 377:\t\t * kvm_gmem_get_pfn()\n 378:\t\t * slot-\u003egmem.file == A\n 379:\t\t \t\t\t\t\tkvm_gmem_release())\n 380:\t\t \t\t\t\t\t slot-\u003egmem.file = NULL\n 381:\t\t \n 382:\t\t \t\t\t\t\tkvm_set_memory_region()\n 383:\t\t \t\t\t\t\t slot deleted\n 384:\t\t \n 385:\t\t \t\t\t\t\tkvm_set_memory_region()\n 386:\t\t \t\t\t\t\t slot created\n 387:\t\t *\t\t\t\t\t slot-\u003egmem.file = B (alloc the same object)\n" }
55/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 29252 output: 39 thoughts: 16 Thoughts: Okay, here's my interpretation of that thought process, assuming I'm an expert in this field, presented as a first-person summary: Diving Deeper into `kvm_gmem_release` Alright, so we're looking at `kvm_gmem_release`. My initial understanding, from prior context, likely tells me what the intended function is. But I know that merely stating the function is not enough, as often the devil is in the details, or in this case, the implementation. Now, the natural progression is to get a clearer picture. What does it actually do? To understand its behavior, to debug a problem, or optimize performance, I need to see the function's internals. I need to understand what's happening at a granular level. So, my next logical step is to delve into the code itself. "Let's read further down in `kvm_gmem_release`" implies this is the first step toward getting more information on how the system is currently working. I am now prepared to dig in and understand.
56/3	2026/10/26 07:33	tool	read-file	0m Args: { "File": "virt/kvm/guest_memfd.c", "FirstLine": 388, "LineCount": 40 } Results: { "Contents": " 388:\t\t \n 389:\t\t get_file_active()\n 390:\t\t * file = B\n 391:\t\t * file_reloaded = B\n 392:\t\t \n 393:\t\t \u003cKVM does weird things with an old memslot + new file\u003e\n 394:\t\t \n 395:\t\t Obviously KVM would be broken in many places if the synchronization\n 396:\t\t * were omitted, but it's important to note that get_file_active() does\n 397:\t\t * NOT guarantee a reference to the \"original\" file was obtained, only\n 398:\t\t * that it grabbed a reference for the returned file, i.e. didn't grab\n 399:\t\t * a reference for file A, but then returned a pointer to file B.\n 400:\t\t /\n 401:\t\txa_for_each(\u0026f-\u003ebindings, index, slot)\n 402:\t\t\tWRITE_ONCE(slot-\u003egmem.file, NULL);\n 403:\t\n 404:\t\t/\n 405:\t\t * All in-flight operations are gone and new bindings can be created.\n 406:\t\t * Zap all SPTEs pointed at by this file. Do not free the backing\n 407:\t\t * memory, as its lifetime is associated with the inode, not the file.\n 408:\t\t /\n 409:\t\t__kvm_gmem_invalidate_start(f, 0, -1ul,\n 410:\t\t\t\t\t kvm_gmem_get_all_gfns_filter(inode));\n 411:\t\t__kvm_gmem_invalidate_end(f, 0, -1ul);\n 412:\t\n 413:\t\tlist_del(\u0026f-\u003eentry);\n 414:\t\n 415:\t\tfilemap_invalidate_unlock(inode-\u003ei_mapping);\n 416:\t\n 417:\t\tmutex_unlock(\u0026kvm-\u003eslots_lock);\n 418:\t\n 419:\t\txa_destroy(\u0026f-\u003ebindings);\n 420:\t\tkfree(f);\n 421:\t\n 422:\t\tkvm_put_kvm(kvm);\n 423:\t\n 424:\t\treturn 0;\n 425:\t}\n 426:\t\n 427:\tstatic inline struct file kvm_gmem_get_file(struct kvm_memory_slot *slot)\n" }
57/3	2026/10/26 07:33	llm	kmsan-evaluator	0m Model: gemini-3.8-flash Args: null Results: null Tokens: input: 30177 output: 337 thoughts: 1830 Thoughts: KMSAN Analysis: Determining `NeedsKMSAN` Okay, let's break this down. My goal is to determine whether this patch requires KMSAN or if standard debug tools like KASAN and LOCKDEP suffice. The core of this patch seems to introduce a new ioctl, `KVM_LINK_GUEST_MEMFD`, and the related `kvm_gmem_link()` function, allowing for linking a guest memory file descriptor (memfd) between VMs. I need to methodically check for potential uninitialized memory risks. First, I see the code adds and removes from `gmem_file_list` is synchronized using `filemap_invalidate_lock(inode->i_mapping)`. I'll keep that in mind. I'll check the locking primitives and reference counting, looking for common memory safety risks. I see `filemap_invalidate_lock`, `slots_lock` are the main synchronization primitives here, and other calls like `fops_get`, `ihold`, `fdget` that suggest reference-counting. I'll make sure to verify those. Now, memory safety. I want to check for uninitialized memory risks. Let me see what's being copied from userspace. The input parameters are copied with `copy_from_user(&params, ...)`. The code then uses this `params` struct. I'll verify that no uninitialized fields are used. I see no issues with that after the copy. I'll make sure there's no kernel memory leaking to user space. It looks like the ioctl returns an integer (the file descriptor) or an error code. There's no data being copied back to user space. That's good. No risks there. I also check for any padding leaks or information leaks. There's none. Now I need to carefully review the prompt's instructions for setting `NeedsKMSAN`. It explicitly states that KMSAN is only needed if there are risks related to uninitialized memory detectable only by KMSAN. If the risks are already covered by KASAN, LOCKDEP, or other standard detectors, then `NeedsKMSAN` is false. The prompt outlines the specific scenarios that would trigger KMSAN: kernel structures sent to userspace with uninitialized fields, conditional logic based on uninitialized variables, complex data structure initialization with uninitialized fields that might be read later, and bounds checks that expose uninitialized bytes. So, let's go through the checklist. Are kernel structures sent to userspace that might contain uninitialized fields? Nope. The ioctl returns an `int` (fd or error code). No data is copied to userspace. Conditional logic based on potentially uninitialized variables? The `copy_from_user` call handles that. Allocation and initialization of complex data structures where uninitialized fields could be read? The `gmem_file` struct is allocated using `kzalloc_obj`, which zero-initializes the struct, so no risks there. Bounds checks that allow access to uninitialized bytes of existing buffers? Nope. The code deals with linking the file. The memory handling of the file itself is unchanged. So, all the potential bugs seem to be related to file descriptor lifecycle, reference counting (kvm, inode, file), and locking, which are all within the scope of KASAN and LOCKDEP. KMSAN isn't needed here. The prompt is very explicit about this. Therefore, the reasoning is clear. KASAN, LOCKDEP, and standard tools are sufficient to detect the potential issues, because the code does not introduce new uninitialized memory risks. `NeedsKMSAN` must be set to `false`. I'm confident in this assessment. Let's call `set-results`.
58/3	2026/10/26 07:34	tool	set-results	0m Args: { "KMSANReasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl, enabling an existing guest_memfd file to be linked into a second VM by creating a new struct file sharing the underlying inode.\n\n1. No Info-leaks / User-space Copies: The ioctl takes an input struct kvm_link_guest_memfd copied from user space via copy_from_user() and only returns an integer file descriptor (or negative error code) via the ioctl return value. No kernel structures or data buffers are copied back to user space (no copy_to_user, put_user, or socket/netlink/bpf buffers), so there is no risk of uninitialized struct padding or data leaks.\n2. Initialization of Structs: The newly allocated struct gmem_file is allocated via kzalloc_obj(), which zero-initializes all bytes. Other local stack variables (such as struct timespec64 ts) are written before being read.\n3. Memory / Concurrency Bugs Caught by KASAN/LOCKDEP: Any potential risks introduced by this feature relate to reference counting (fops, inode, kvm instance, and struct file lifetimes), file descriptor management, or locking interactions (e.g., filemap_invalidate_lock), which are detected by KASAN, refcount tracking, and LOCKDEP rather than KMSAN.\n\nTherefore, this patch does not expose uninitialized memory risks, and a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false } Results: { "KMSANReasoning": "The patch introduces the KVM_LINK_GUEST_MEMFD ioctl, enabling an existing guest_memfd file to be linked into a second VM by creating a new struct file sharing the underlying inode.\n\n1. No Info-leaks / User-space Copies: The ioctl takes an input struct kvm_link_guest_memfd copied from user space via copy_from_user() and only returns an integer file descriptor (or negative error code) via the ioctl return value. No kernel structures or data buffers are copied back to user space (no copy_to_user, put_user, or socket/netlink/bpf buffers), so there is no risk of uninitialized struct padding or data leaks.\n2. Initialization of Structs: The newly allocated struct gmem_file is allocated via kzalloc_obj(), which zero-initializes all bytes. Other local stack variables (such as struct timespec64 ts) are written before being read.\n3. Memory / Concurrency Bugs Caught by KASAN/LOCKDEP: Any potential risks introduced by this feature relate to reference counting (fops, inode, kvm instance, and struct file lifetimes), file descriptor management, or locking interactions (e.g., filemap_invalidate_lock), which are detected by KASAN, refcount tracking, and LOCKDEP rather than KMSAN.\n\nTherefore, this patch does not expose uninitialized memory risks, and a dedicated KMSAN fuzzing session is not warranted.", "NeedsKMSAN": false }

LLM Calls Summary:
Total Calls	Total Tokens	Avg Tokens	Total Duration (Seconds)	Avg Duration (Seconds)

Tool Calls Summary:
Total Calls	Total Duration (Seconds)	Avg Duration (Seconds)