AI Trajectory

null

{
  "EnableConfigs": [
    "IO_URING"
  ],
  "FocusSymbols": [
    "io_create_region",
    "io_free_region",
    "io_uring_mmap"
  ],
  "KMSANReasoning": "The patch introduces a new internal structure `io_region_account` to track memory accounting for io_uring memory regions across VMA lifecycles. The structure is allocated internally and all its fields (`refs`, `user`, `nr_pages`) are explicitly initialized before use. No new data structures are copied to userspace, and no uninitialized memory is exposed or used in control flow. The changes primarily address memory accounting and object lifecycles, where any potential bugs (such as use-after-free or memory leaks) would be effectively caught by KASAN or standard kernel memory leak detectors. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies memory accounting and mapping logic for io_uring regions, introducing `struct io_region_account` and changing how memory is accounted and freed. This affects `io_create_region`, `io_free_region`, and `io_uring_mmap`. These are reachable core kernel logic and should be fuzzed.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 3512947c0d36024efd5119feb5941d5aa0dfd430\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Aug 16 07:29:33 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h\nindex 87151a5b62c1b..6feb7ee3440fd 100644\n--- a/include/linux/io_uring_types.h\n+++ b/include/linux/io_uring_types.h\n@@ -94,11 +94,14 @@ struct io_hash_table {\n \tunsigned\t\thash_bits;\n };\n \n+struct io_region_account;\n+\n struct io_mapped_region {\n \tstruct page\t\t**pages;\n \tvoid\t\t\t*ptr;\n \tunsigned\t\tnr_pages;\n \tunsigned\t\tflags;\n+\tstruct io_region_account\t*account;\n };\n \n /*\ndiff --git a/io_uring/memmap.c b/io_uring/memmap.c\nindex 23e8a85111bca..ca28a9429c168 100644\n--- a/io_uring/memmap.c\n+++ b/io_uring/memmap.c\n@@ -4,6 +4,8 @@\n #include \u003clinux/errno.h\u003e\n #include \u003clinux/mm.h\u003e\n #include \u003clinux/mman.h\u003e\n+#include \u003clinux/refcount.h\u003e\n+#include \u003clinux/sched/user.h\u003e\n #include \u003clinux/slab.h\u003e\n #include \u003clinux/vmalloc.h\u003e\n #include \u003clinux/io_uring.h\u003e\n@@ -88,6 +90,52 @@ enum {\n \tIO_REGION_F_SINGLE_REF\t\t\t= 4,\n };\n \n+struct io_region_account {\n+\trefcount_t refs;\n+\tstruct user_struct *user;\n+\tunsigned long nr_pages;\n+};\n+\n+static struct io_region_account *\n+io_region_account_alloc(struct user_struct *user, unsigned long nr_pages)\n+{\n+\tstruct io_region_account *account;\n+\tint ret;\n+\n+\tif (!user)\n+\t\treturn NULL;\n+\n+\taccount = kmalloc_obj(*account, GFP_KERNEL_ACCOUNT);\n+\tif (!account)\n+\t\treturn ERR_PTR(-ENOMEM);\n+\n+\tret = __io_account_mem(user, nr_pages);\n+\tif (ret) {\n+\t\tkfree(account);\n+\t\treturn ERR_PTR(ret);\n+\t}\n+\n+\trefcount_set(\u0026account-\u003erefs, 1);\n+\taccount-\u003euser = get_uid(user);\n+\taccount-\u003enr_pages = nr_pages;\n+\treturn account;\n+}\n+\n+static void io_region_account_get(struct io_region_account *account)\n+{\n+\tif (account)\n+\t\trefcount_inc(\u0026account-\u003erefs);\n+}\n+\n+static void io_region_account_put(struct io_region_account *account)\n+{\n+\tif (account \u0026\u0026 refcount_dec_and_test(\u0026account-\u003erefs)) {\n+\t\t__io_unaccount_mem(account-\u003euser, account-\u003enr_pages);\n+\t\tfree_uid(account-\u003euser);\n+\t\tkfree(account);\n+\t}\n+}\n+\n void io_free_region(struct user_struct *user, struct io_mapped_region *mr)\n {\n \tif (mr-\u003epages) {\n@@ -105,8 +153,12 @@ void io_free_region(struct user_struct *user, struct io_mapped_region *mr)\n \t}\n \tif ((mr-\u003eflags \u0026 IO_REGION_F_VMAP) \u0026\u0026 mr-\u003eptr)\n \t\tvunmap(mr-\u003eptr);\n-\tif (mr-\u003enr_pages \u0026\u0026 user)\n+\tif (mr-\u003eaccount) {\n+\t\tWARN_ON_ONCE(mr-\u003eaccount-\u003euser != user);\n+\t\tio_region_account_put(mr-\u003eaccount);\n+\t} else if (mr-\u003enr_pages \u0026\u0026 user) {\n \t\t__io_unaccount_mem(user, mr-\u003enr_pages);\n+\t}\n \n \tmemset(mr, 0, sizeof(*mr));\n }\n@@ -188,7 +240,8 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\n \tint nr_pages, ret;\n \tu64 end;\n \n-\tif (WARN_ON_ONCE(mr-\u003epages || mr-\u003eptr || mr-\u003enr_pages))\n+\tif (WARN_ON_ONCE(mr-\u003epages || mr-\u003eptr || mr-\u003enr_pages ||\n+\t\t\t mr-\u003eaccount))\n \t\treturn -EFAULT;\n \tif (memchr_inv(\u0026reg-\u003e__resv, 0, sizeof(reg-\u003e__resv)))\n \t\treturn -EINVAL;\n@@ -207,10 +260,23 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\n \t\treturn -EOVERFLOW;\n \n \tnr_pages = reg-\u003esize \u003e\u003e PAGE_SHIFT;\n-\tif (ctx-\u003euser) {\n-\t\tret = __io_account_mem(ctx-\u003euser, nr_pages);\n-\t\tif (ret)\n+\tif (reg-\u003eflags \u0026 IORING_MEM_REGION_TYPE_USER) {\n+\t\tif (ctx-\u003euser) {\n+\t\t\tret = __io_account_mem(ctx-\u003euser, nr_pages);\n+\t\t\tif (ret)\n+\t\t\t\treturn ret;\n+\t\t}\n+\t} else {\n+\t\t/*\n+\t\t * Kernel-allocated pages can outlive their active region through\n+\t\t * userspace mappings.\n+\t\t */\n+\t\tmr-\u003eaccount = io_region_account_alloc(ctx-\u003euser, nr_pages);\n+\t\tif (IS_ERR(mr-\u003eaccount)) {\n+\t\t\tret = PTR_ERR(mr-\u003eaccount);\n+\t\t\tmr-\u003eaccount = NULL;\n \t\t\treturn ret;\n+\t\t}\n \t}\n \tmr-\u003enr_pages = nr_pages;\n \n@@ -281,15 +347,41 @@ static void *io_uring_validate_mmap_request(struct file *file, loff_t pgoff)\n \n #ifdef CONFIG_MMU\n \n+static void io_region_vm_open(struct vm_area_struct *vma)\n+{\n+\tio_region_account_get(vma-\u003evm_private_data);\n+}\n+\n+static void io_region_vm_close(struct vm_area_struct *vma)\n+{\n+\tio_region_account_put(vma-\u003evm_private_data);\n+}\n+\n+static const struct vm_operations_struct io_region_vm_ops = {\n+\t.open = io_region_vm_open,\n+\t.close = io_region_vm_close,\n+};\n+\n static int io_region_mmap(struct io_ring_ctx *ctx,\n \t\t\t  struct io_mapped_region *mr,\n \t\t\t  struct vm_area_struct *vma,\n \t\t\t  unsigned max_pages)\n {\n \tunsigned long nr_pages = min(mr-\u003enr_pages, max_pages);\n+\tint ret;\n \n \tvm_flags_set(vma, VM_DONTEXPAND);\n-\treturn vm_insert_pages(vma, vma-\u003evm_start, mr-\u003epages, \u0026nr_pages);\n+\tret = vm_insert_pages(vma, vma-\u003evm_start, mr-\u003epages, \u0026nr_pages);\n+\tif (!ret \u0026\u0026 mr-\u003eaccount) {\n+\t\t/*\n+\t\t * Accounting deliberately remains at region granularity when\n+\t\t * this VMA maps only part of the region.\n+\t\t */\n+\t\tvma-\u003evm_private_data = mr-\u003eaccount;\n+\t\tvma-\u003evm_ops = \u0026io_region_vm_ops;\n+\t\tvma-\u003evm_ops-\u003eopen(vma);\n+\t}\n+\treturn ret;\n }\n \n __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\n@@ -379,6 +471,8 @@ static void io_uring_nommu_vm_close(struct vm_area_struct *vma)\n \n \tfor (index = vma-\u003evm_start; index \u003c vma-\u003evm_end; index += PAGE_SIZE)\n \t\tput_page(virt_to_page((void *) index));\n+\n+\tio_region_account_put(vma-\u003evm_private_data);\n }\n \n static const struct vm_operations_struct io_uring_nommu_vm_ops = {\n@@ -411,6 +505,8 @@ int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\n \tfor (i = 0; i \u003c region-\u003enr_pages; i++)\n \t\tget_page(region-\u003epages[i]);\n \n+\tvma-\u003evm_private_data = region-\u003eaccount;\n+\tio_region_account_get(region-\u003eaccount);\n \tvma-\u003evm_ops = \u0026io_uring_nommu_vm_ops;\n \treturn 0;\n }\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "IO_URING"
  ],
  "FocusSymbols": [
    "io_create_region",
    "io_free_region",
    "io_uring_mmap"
  ],
  "Reasoning": "The patch modifies memory accounting and mapping logic for io_uring regions, introducing `struct io_region_account` and changing how memory is accounted and freed. This affects `io_create_region`, `io_free_region`, and `io_uring_mmap`. These are reachable core kernel logic and should be fuzzed.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


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

For your convenience, here is the diff of the changes:
commit 3512947c0d36024efd5119feb5941d5aa0dfd430
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 16 07:29:33 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
index 87151a5b62c1b..6feb7ee3440fd 100644
--- a/include/linux/io_uring_types.h
+++ b/include/linux/io_uring_types.h
@@ -94,11 +94,14 @@ struct io_hash_table {
 	unsigned		hash_bits;
 };
 
+struct io_region_account;
+
 struct io_mapped_region {
 	struct page		**pages;
 	void			*ptr;
 	unsigned		nr_pages;
 	unsigned		flags;
+	struct io_region_account	*account;
 };
 
 /*
diff --git a/io_uring/memmap.c b/io_uring/memmap.c
index 23e8a85111bca..ca28a9429c168 100644
--- a/io_uring/memmap.c
+++ b/io_uring/memmap.c
@@ -4,6 +4,8 @@
 #include <linux/errno.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/refcount.h>
+#include <linux/sched/user.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
 #include <linux/io_uring.h>
@@ -88,6 +90,52 @@ enum {
 	IO_REGION_F_SINGLE_REF			= 4,
 };
 
+struct io_region_account {
+	refcount_t refs;
+	struct user_struct *user;
+	unsigned long nr_pages;
+};
+
+static struct io_region_account *
+io_region_account_alloc(struct user_struct *user, unsigned long nr_pages)
+{
+	struct io_region_account *account;
+	int ret;
+
+	if (!user)
+		return NULL;
+
+	account = kmalloc_obj(*account, GFP_KERNEL_ACCOUNT);
+	if (!account)
+		return ERR_PTR(-ENOMEM);
+
+	ret = __io_account_mem(user, nr_pages);
+	if (ret) {
+		kfree(account);
+		return ERR_PTR(ret);
+	}
+
+	refcount_set(&account->refs, 1);
+	account->user = get_uid(user);
+	account->nr_pages = nr_pages;
+	return account;
+}
+
+static void io_region_account_get(struct io_region_account *account)
+{
+	if (account)
+		refcount_inc(&account->refs);
+}
+
+static void io_region_account_put(struct io_region_account *account)
+{
+	if (account && refcount_dec_and_test(&account->refs)) {
+		__io_unaccount_mem(account->user, account->nr_pages);
+		free_uid(account->user);
+		kfree(account);
+	}
+}
+
 void io_free_region(struct user_struct *user, struct io_mapped_region *mr)
 {
 	if (mr->pages) {
@@ -105,8 +153,12 @@ void io_free_region(struct user_struct *user, struct io_mapped_region *mr)
 	}
 	if ((mr->flags & IO_REGION_F_VMAP) && mr->ptr)
 		vunmap(mr->ptr);
-	if (mr->nr_pages && user)
+	if (mr->account) {
+		WARN_ON_ONCE(mr->account->user != user);
+		io_region_account_put(mr->account);
+	} else if (mr->nr_pages && user) {
 		__io_unaccount_mem(user, mr->nr_pages);
+	}
 
 	memset(mr, 0, sizeof(*mr));
 }
@@ -188,7 +240,8 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
 	int nr_pages, ret;
 	u64 end;
 
-	if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages))
+	if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages ||
+			 mr->account))
 		return -EFAULT;
 	if (memchr_inv(&reg->__resv, 0, sizeof(reg->__resv)))
 		return -EINVAL;
@@ -207,10 +260,23 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
 		return -EOVERFLOW;
 
 	nr_pages = reg->size >> PAGE_SHIFT;
-	if (ctx->user) {
-		ret = __io_account_mem(ctx->user, nr_pages);
-		if (ret)
+	if (reg->flags & IORING_MEM_REGION_TYPE_USER) {
+		if (ctx->user) {
+			ret = __io_account_mem(ctx->user, nr_pages);
+			if (ret)
+				return ret;
+		}
+	} else {
+		/*
+		 * Kernel-allocated pages can outlive their active region through
+		 * userspace mappings.
+		 */
+		mr->account = io_region_account_alloc(ctx->user, nr_pages);
+		if (IS_ERR(mr->account)) {
+			ret = PTR_ERR(mr->account);
+			mr->account = NULL;
 			return ret;
+		}
 	}
 	mr->nr_pages = nr_pages;
 
@@ -281,15 +347,41 @@ static void *io_uring_validate_mmap_request(struct file *file, loff_t pgoff)
 
 #ifdef CONFIG_MMU
 
+static void io_region_vm_open(struct vm_area_struct *vma)
+{
+	io_region_account_get(vma->vm_private_data);
+}
+
+static void io_region_vm_close(struct vm_area_struct *vma)
+{
+	io_region_account_put(vma->vm_private_data);
+}
+
+static const struct vm_operations_struct io_region_vm_ops = {
+	.open = io_region_vm_open,
+	.close = io_region_vm_close,
+};
+
 static int io_region_mmap(struct io_ring_ctx *ctx,
 			  struct io_mapped_region *mr,
 			  struct vm_area_struct *vma,
 			  unsigned max_pages)
 {
 	unsigned long nr_pages = min(mr->nr_pages, max_pages);
+	int ret;
 
 	vm_flags_set(vma, VM_DONTEXPAND);
-	return vm_insert_pages(vma, vma->vm_start, mr->pages, &nr_pages);
+	ret = vm_insert_pages(vma, vma->vm_start, mr->pages, &nr_pages);
+	if (!ret && mr->account) {
+		/*
+		 * Accounting deliberately remains at region granularity when
+		 * this VMA maps only part of the region.
+		 */
+		vma->vm_private_data = mr->account;
+		vma->vm_ops = &io_region_vm_ops;
+		vma->vm_ops->open(vma);
+	}
+	return ret;
 }
 
 __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
@@ -379,6 +471,8 @@ static void io_uring_nommu_vm_close(struct vm_area_struct *vma)
 
 	for (index = vma->vm_start; index < vma->vm_end; index += PAGE_SIZE)
 		put_page(virt_to_page((void *) index));
+
+	io_region_account_put(vma->vm_private_data);
 }
 
 static const struct vm_operations_struct io_uring_nommu_vm_ops = {
@@ -411,6 +505,8 @@ int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
 	for (i = 0; i < region->nr_pages; i++)
 		get_page(region->pages[i]);
 
+	vma->vm_private_data = region->account;
+	io_region_account_get(region->account);
 	vma->vm_ops = &io_uring_nommu_vm_ops;
 	return 0;
 }

gemini-3.1-pro-preview

null

null

							input: 4040
							output: 18
							thoughts: 244
						

**My Assessment of the io_uring Memory Accounting Patch**

Okay, so I'm looking at this patch that tweaks the memory accounting within `io_uring/memmap.c` and `include/linux/io_uring_types.h`. It seems we're dealing with the introduction of this `struct io_region_account` and a refactor of how `io_mapped_region` memory is tracked. The patch is adding `io_region_account_alloc`, `io_region_account_get`, and `io_region_account_put` which immediately tells me this is about reference counting or a similar mechanism for managing the lifetime of these regions. It's also modifying `io_free_region`, `io_create_region`, and both `io_region_mmap` and the `io_uring_mmap` for nommu systems.

This is a pretty significant functional change – it goes right to the heart of how io_uring manages memory mapping. Given that, it's definitely reachable code and a prime target for fuzzing. I need to zero in on the key functions to focus my fuzzing efforts. From what I see now, `io_create_region`, `io_free_region`, and `io_uring_mmap` are going to be my primary targets.

Before I dive too deep into writing test cases, I should double-check the configuration dependencies. Obviously, `CONFIG_IO_URING` is the big one, but I'll need to confirm that. I'll need to check either `io_uring/Kconfig` or possibly even `init/Kconfig` to see if there are any subtle configuration options that might affect the behavior of these functions or introduce edge cases that I need to account for. I need to be sure I'm testing the code as it would be configured in the real world.

{
  "Expression": "config IO_URING"
}

{
  "Output": "init/Kconfig=1910=config AIO\n--\ninit/Kconfig-1917-\ninit/Kconfig:1918:config IO_URING\ninit/Kconfig-1919-\tbool \"Enable IO uring support\" if EXPERT\n--\ninit/Kconfig=1927=config GCOV_PROFILE_URING\n--\ninit/Kconfig-1939-\ninit/Kconfig:1940:config IO_URING_MOCK_FILE\ninit/Kconfig-1941-\ttristate \"Enable io_uring mock files (Experimental)\" if EXPERT\n--\nio_uring/Kconfig-5-\nio_uring/Kconfig:6:config IO_URING_ZCRX\nio_uring/Kconfig-7-\tdef_bool y\n--\nio_uring/Kconfig-12-\nio_uring/Kconfig:13:config IO_URING_BPF\nio_uring/Kconfig-14-\tdef_bool y\n--\nio_uring/Kconfig-17-\nio_uring/Kconfig:18:config IO_URING_BPF_OPS\nio_uring/Kconfig-19-\tdef_bool y\n"
}

gemini-3.1-pro-preview

null

null

							input: 4999
							output: 19
							thoughts: 28
						

Here's my summary, as though I were thinking through the process:

**Diving into the IO_URING Configuration**

Okay, so we're dealing with an `IO_URING` configuration here. Right. Now, I need to get a handle on how memory regions are managed within this context. My primary concern is with the allocation and deallocation strategies for I/O buffers. So, I need to really understand the roles of `io_create_region` and `io_free_region`. These functions are central to the integrity and performance of the I/O system, and I have to fully grasp their interaction. I need to trace their implementation, understand any potential overhead they introduce, and how they relate to the underlying memory management mechanisms. Essentially, I need to ensure that the region creation and destruction are robust and optimally designed, and that these functions don't become performance bottlenecks.

{
  "Expression": "io_create_region"
}

{
  "Output": "io_uring/io_uring.c=2726=static __cold int io_allocate_scq_urings(struct io_ring_ctx *ctx,\n--\nio_uring/io_uring.c-2744-\t}\nio_uring/io_uring.c:2745:\tret = io_create_region(ctx, \u0026ctx-\u003ering_region, \u0026rd, IORING_OFF_CQ_RING);\nio_uring/io_uring.c-2746-\tif (ret)\n--\nio_uring/io_uring.c-2758-\t}\nio_uring/io_uring.c:2759:\tret = io_create_region(ctx, \u0026ctx-\u003esq_region, \u0026rd, IORING_OFF_SQES);\nio_uring/io_uring.c-2760-\tif (ret) {\n--\nio_uring/kbuf.c=629=int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)\n--\nio_uring/kbuf.c-677-\t}\nio_uring/kbuf.c:678:\tret = io_create_region(ctx, \u0026bl-\u003eregion, \u0026rd, mmap_offset);\nio_uring/kbuf.c-679-\tif (ret)\n--\nio_uring/memmap.c=204=static int io_region_allocate_pages(struct io_mapped_region *mr,\n--\nio_uring/memmap.c-235-\nio_uring/memmap.c:236:int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\nio_uring/memmap.c-237-\t\t     struct io_uring_region_desc *reg,\n--\nio_uring/memmap.h=20=void io_free_region(struct user_struct *user, struct io_mapped_region *mr);\nio_uring/memmap.h:21:int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\nio_uring/memmap.h-22-\t\t     struct io_uring_region_desc *reg,\n--\nio_uring/register.c=498=static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg)\n--\nio_uring/register.c-531-\t}\nio_uring/register.c:532:\tret = io_create_region(ctx, \u0026n.ring_region, \u0026rd, IORING_OFF_CQ_RING);\nio_uring/register.c-533-\tif (ret)\n--\nio_uring/register.c-561-\t}\nio_uring/register.c:562:\tret = io_create_region(ctx, \u0026n.sq_region, \u0026rd, IORING_OFF_SQES);\nio_uring/register.c-563-\tif (ret) {\n--\nio_uring/register.c=703=static int io_register_mem_region(struct io_ring_ctx *ctx, void __user *uarg)\n--\nio_uring/register.c-732-\nio_uring/register.c:733:\tret = io_create_region(ctx, \u0026region, \u0026rd, IORING_MAP_OFF_PARAM_REGION);\nio_uring/register.c-734-\tif (ret)\n--\nio_uring/zcrx.c=380=static int io_allocate_rbuf_ring(struct io_ring_ctx *ctx,\n--\nio_uring/zcrx.c-399-\nio_uring/zcrx.c:400:\tret = io_create_region(ctx, \u0026ifq-\u003erq_region, rd, mmap_offset);\nio_uring/zcrx.c-401-\tif (ret \u003c 0)\n"
}

gemini-3.1-pro-preview

null

null

							input: 6225
							output: 19
							thoughts: 74
						

Okay, here's my take on those functions.

**Initial Considerations for Memory Management**

Right, so we're diving into memory management within this system, and my immediate focus lands on these specific functions: `io_create_region`, `io_free_region`, `io_uring_mmap`, `io_register_mem_region`, `io_register_pbuf_ring`, and `io_register_resize_rings`. It seems these are the core building blocks for how memory regions are created, freed, mapped with io_uring, and registered for various purposes – probably to serve the io_uring operations. I'm keen to understand how they work together, but given their names, I'm expecting some kind of layered approach here for both the memory and rings.

My gut tells me a good starting point to unpick the architecture is to have a look at `io_free_region`. That'll be a useful place to start because it should give me a good handle on how the resources are managed from beginning to end. Knowing how memory is deallocated is often key to understanding the allocation process and identifying potential vulnerabilities or inefficiencies.

{
  "Expression": "io_free_region"
}

{
  "Output": "io_uring/io_uring.c=2078=static void io_rings_free(struct io_ring_ctx *ctx)\nio_uring/io_uring.c-2079-{\nio_uring/io_uring.c:2080:\tio_free_region(ctx-\u003euser, \u0026ctx-\u003esq_region);\nio_uring/io_uring.c:2081:\tio_free_region(ctx-\u003euser, \u0026ctx-\u003ering_region);\nio_uring/io_uring.c-2082-\tctx-\u003erings = NULL;\n--\nio_uring/io_uring.c=2163=static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)\n--\nio_uring/io_uring.c-2175-\tio_destroy_buffers(ctx);\nio_uring/io_uring.c:2176:\tio_free_region(ctx-\u003euser, \u0026ctx-\u003eparam_region);\nio_uring/io_uring.c-2177-\tmutex_unlock(\u0026ctx-\u003euring_lock);\n--\nio_uring/kbuf.c=458=static void io_put_bl(struct io_ring_ctx *ctx, struct io_buffer_list *bl)\n--\nio_uring/kbuf.c-460-\tif (bl-\u003eflags \u0026 IOBL_BUF_RING)\nio_uring/kbuf.c:461:\t\tio_free_region(ctx-\u003euser, \u0026bl-\u003eregion);\nio_uring/kbuf.c-462-\telse\n--\nio_uring/kbuf.c=629=int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)\n--\nio_uring/kbuf.c-710-fail:\nio_uring/kbuf.c:711:\tio_free_region(ctx-\u003euser, \u0026bl-\u003eregion);\nio_uring/kbuf.c-712-\tkfree(bl);\n--\nio_uring/memmap.c=130=static void io_region_account_put(struct io_region_account *account)\n--\nio_uring/memmap.c-138-\nio_uring/memmap.c:139:void io_free_region(struct user_struct *user, struct io_mapped_region *mr)\nio_uring/memmap.c-140-{\n--\nio_uring/memmap.c=236=int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\n--\nio_uring/memmap.c-294-out_free:\nio_uring/memmap.c:295:\tio_free_region(ctx-\u003euser, mr);\nio_uring/memmap.c-296-\treturn ret;\n--\nio_uring/memmap.c=482=int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\n--\nio_uring/memmap.c-500-\t/*\nio_uring/memmap.c:501:\t * Pin the pages so io_free_region()'s release_pages() does not\nio_uring/memmap.c-502-\t * drop the last reference while this VMA exists. delete_vma()\n--\nio_uring/memmap.h=18=int io_uring_mmap(struct file *file, struct vm_area_struct *vma);\nio_uring/memmap.h-19-\nio_uring/memmap.h:20:void io_free_region(struct user_struct *user, struct io_mapped_region *mr);\nio_uring/memmap.h-21-int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,\n--\nio_uring/register.c=480=static void io_register_free_rings(struct io_ring_ctx *ctx,\n--\nio_uring/register.c-482-{\nio_uring/register.c:483:\tio_free_region(ctx-\u003euser, \u0026r-\u003esq_region);\nio_uring/register.c:484:\tio_free_region(ctx-\u003euser, \u0026r-\u003ering_region);\nio_uring/register.c-485-}\n--\nio_uring/register.c=703=static int io_register_mem_region(struct io_ring_ctx *ctx, void __user *uarg)\n--\nio_uring/register.c-736-\tif (copy_to_user(rd_uptr, \u0026rd, sizeof(rd))) {\nio_uring/register.c:737:\t\tio_free_region(ctx-\u003euser, \u0026region);\nio_uring/register.c-738-\t\treturn -EFAULT;\n--\nio_uring/zcrx.c=412=static void io_free_rbuf_ring(struct io_zcrx_ifq *ifq)\nio_uring/zcrx.c-413-{\nio_uring/zcrx.c:414:\tio_free_region(ifq-\u003euser, \u0026ifq-\u003erq_region);\nio_uring/zcrx.c-415-\tifq-\u003erq.ring = IO_URING_PTR_POISON;\n"
}

gemini-3.1-pro-preview

null

null

							input: 7891
							output: 20
							thoughts: 63
						

**My Initial Assessment of the I/O Region Functions**

Okay, here's what I'm thinking. We've got a handful of critical I/O region functions to zero in on: `io_create_region`, `io_free_region`, `io_uring_mmap`, `io_region_mmap`, and `io_register_mem_region`. Given what I know about memory management and the kernel, these are likely the core building blocks for how these regions are created, managed, and mapped. My gut tells me that any issues here could ripple out and cause significant problems further down the line, so it's best to investigate them thoroughly. My first instinct, given the list and its context, is to delve into `io_region_mmap`. Understanding how these regions are actually mapped into the user space or kernel address space seems like the logical starting point to gain insights and to start to determine how this is all implemented at the lower levels. Let's see what that function is up to.

{
  "Expression": "io_region_mmap"
}

{
  "Output": "io_uring/memmap.c=360=static const struct vm_operations_struct io_region_vm_ops = {\n--\nio_uring/memmap.c-364-\nio_uring/memmap.c:365:static int io_region_mmap(struct io_ring_ctx *ctx,\nio_uring/memmap.c-366-\t\t\t  struct io_mapped_region *mr,\n--\nio_uring/memmap.c=387=__cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\n--\nio_uring/memmap.c-409-\tregion = io_mmap_get_region(ctx, vma-\u003evm_pgoff);\nio_uring/memmap.c:410:\treturn io_region_mmap(ctx, region, vma, page_limit);\nio_uring/memmap.c-411-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 8434
							output: 21
							thoughts: 28
						

Here's my summary, as though I'm thinking through this process:

**Diving into io_uring's Memory Management**

Okay, so I'm starting with `io_uring_mmap`. That's where it all begins, right? The initial mapping. Now, I need to understand how the memory registration actually works within that context. I'll need to go deeper to see how `io_uring` interacts with the underlying system memory. Let's dig into `io_register_mem_region` next; I'm pretty sure that's the key to understanding how user-space memory gets plumbed into `io_uring`'s world. I want to see how that registration ties into the whole picture, especially regarding DMA and those potential performance optimizations that are the whole point of `io_uring`. I'm expecting some interesting interaction with page tables here.

{
  "Expression": "io_register_mem_region"
}

{
  "Output": "io_uring/register.c=498=static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg)\n--\nio_uring/register.c-702-\nio_uring/register.c:703:static int io_register_mem_region(struct io_ring_ctx *ctx, void __user *uarg)\nio_uring/register.c-704-{\n--\nio_uring/register.c=750=static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,\n--\nio_uring/register.c-953-\t\t\tbreak;\nio_uring/register.c:954:\t\tret = io_register_mem_region(ctx, arg);\nio_uring/register.c-955-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 8887
							output: 22
							thoughts: 35
						

Here's my take on the thought process, as if it were my own:

**Investigating Memory Registration in the IO_uring Context**

Okay, so `io_register_mem_region` is definitely triggered by `__io_uring_register`. Makes sense; that's the core registration function. My instinct is to understand the flow here so, let's trace this and see what's happening internally. I'm especially interested in memory management nuances so I'll check `io_register_pbuf_ring` for some context around that...

{
  "Expression": "io_register_pbuf_ring"
}

{
  "Output": "io_uring/kbuf.c=611=int io_manage_buffers_legacy(struct io_kiocb *req, unsigned int issue_flags)\n--\nio_uring/kbuf.c-628-\nio_uring/kbuf.c:629:int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg)\nio_uring/kbuf.c-630-{\n--\nio_uring/kbuf.h=80=int io_manage_buffers_legacy(struct io_kiocb *req, unsigned int issue_flags);\nio_uring/kbuf.h-81-\nio_uring/kbuf.h:82:int io_register_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg);\nio_uring/kbuf.h-83-int io_unregister_pbuf_ring(struct io_ring_ctx *ctx, void __user *arg);\n--\nio_uring/register.c=750=static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,\n--\nio_uring/register.c-887-\t\t\tbreak;\nio_uring/register.c:888:\t\tret = io_register_pbuf_ring(ctx, arg);\nio_uring/register.c-889-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 9410
							output: 21
							thoughts: 35
						

Here's a summary of my immediate thought process:

**Diving into io_register_pbuf_ring**

Okay, so `io_register_pbuf_ring` is called from `__io_uring_register`. That's the entry point, the registration path. It's time to follow the trail. I need to understand how the buffer rings are being set up. My next logical step is to examine the resize operation. Let's dig into `io_register_resize_rings`. That should give me the lowdown on the ring sizes, and how the buffer memory is allocated and managed during this initialization phase.

{
  "Expression": "io_register_resize_rings"
}

{
  "Output": "io_uring/register.c=480=static void io_register_free_rings(struct io_ring_ctx *ctx,\n--\nio_uring/register.c-497-\nio_uring/register.c:498:static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg)\nio_uring/register.c-499-{\n--\nio_uring/register.c=750=static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,\n--\nio_uring/register.c-947-\t\t\tbreak;\nio_uring/register.c:948:\t\tret = io_register_resize_rings(ctx, arg);\nio_uring/register.c-949-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 9809
							output: 21
							thoughts: 249
						

**My Analysis of `io_uring` Ring Registration**

Okay, so I'm tracing the calls related to registering and resizing the rings within the `io_uring` subsystem. My starting point is `io_register_resize_rings`, which I see is called directly from `__io_uring_register`. Therefore, that's where I need to focus.

My attention immediately shifts to several functions: `io_create_region`, `io_free_region`, `io_uring_mmap`, `io_register_mem_region`, `io_register_pbuf_ring`, and `io_register_resize_rings`.

Now, `io_create_region` and `io_free_region` catch my eye. They aren't declared as static, which is interesting, even if they are internal to `io_uring`. This means they're accessible outside a specific source file, so are probably worth scrutinizing. I see that `io_register_mem_region`, `io_register_pbuf_ring`, and `io_register_resize_rings` also seem important.

A quick check confirms a couple of things, and triggers an error in my thinking. `io_register_mem_region` is, in fact, static. *And*, so is `io_register_resize_rings`. My initial mental model was flawed. On the other hand, `io_register_pbuf_ring` and `io_uring_mmap` are *not* static, so will be useful.

I need to circle back and confirm my understanding of `io_register_mem_region` and `io_register_resize_rings`. They're internal, so are they the right places to focus?

{
  "Expression": "io_register_mem_region"
}

{
  "Output": "io_uring/register.c=498=static int io_register_resize_rings(struct io_ring_ctx *ctx, void __user *arg)\n--\nio_uring/register.c-702-\nio_uring/register.c:703:static int io_register_mem_region(struct io_ring_ctx *ctx, void __user *uarg)\nio_uring/register.c-704-{\n--\nio_uring/register.c=750=static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,\n--\nio_uring/register.c-953-\t\t\tbreak;\nio_uring/register.c:954:\t\tret = io_register_mem_region(ctx, arg);\nio_uring/register.c-955-\t\tbreak;\n"
}

gemini-3.1-pro-preview

null

null

							input: 10666
							output: 20
							thoughts: 236
						

**Focusing on Key IO Functions**

Alright, let's break this down. Given that `io_register_mem_region` is static, my attention needs to shift to the more dynamic components. I need to focus on the non-static functions related to IO region management, which are where the core interactions likely reside. Specifically, `io_create_region`, `io_free_region`, `io_uring_mmap`, and `io_register_pbuf_ring`. Perhaps, although maybe too broad as an entry point, `__io_uring_register` deserves a second look.

Okay, let me confirm the static/non-static status of those first four again: Yup, `io_create_region`, `io_free_region`, `io_uring_mmap`, and `io_register_pbuf_ring` are all non-static, which is what I expect.

Just to be thorough, I'm going to quickly glance at any other potentially related functions. Looks like `io_region_account_alloc`, `io_region_account_get`, and `io_region_account_put` are static, so I can probably keep those out of the scope for now.

Considering the non-static functions, the most promising candidates are `io_create_region`, `io_free_region`, and `io_uring_mmap` based on their role in region lifecycle and mapping.

I think it's time to dive into a deeper analysis of `io_uring_mmap`.

{
  "Expression": "io_uring_mmap"
}

{
  "Output": "io_uring/io_uring.c=2708=static const struct file_operations io_uring_fops = {\nio_uring/io_uring.c-2709-\t.release\t= io_uring_release,\nio_uring/io_uring.c:2710:\t.mmap\t\t= io_uring_mmap,\nio_uring/io_uring.c-2711-\t.get_unmapped_area = io_uring_get_unmapped_area,\n--\nio_uring/memmap.c=365=static int io_region_mmap(struct io_ring_ctx *ctx,\n--\nio_uring/memmap.c-386-\nio_uring/memmap.c:387:__cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\nio_uring/memmap.c-388-{\n--\nio_uring/memmap.c=413=unsigned long io_uring_get_unmapped_area(struct file *filp, unsigned long addr,\n--\nio_uring/memmap.c-462- * Drop the pages that were initially referenced and added in\nio_uring/memmap.c:463: * io_uring_mmap(). We cannot have had a mremap() as that isn't supported,\nio_uring/memmap.c-464- * hence the vma should be identical to the one we initially referenced and\n--\nio_uring/memmap.c=478=static const struct vm_operations_struct io_uring_nommu_vm_ops = {\n--\nio_uring/memmap.c-481-\nio_uring/memmap.c:482:int io_uring_mmap(struct file *file, struct vm_area_struct *vma)\nio_uring/memmap.c-483-{\n--\nio_uring/memmap.h=15=unsigned long io_uring_get_unmapped_area(struct file *file, unsigned long addr,\n--\nio_uring/memmap.h-17-\t\t\t\t\t unsigned long flags);\nio_uring/memmap.h:18:int io_uring_mmap(struct file *file, struct vm_area_struct *vma);\nio_uring/memmap.h-19-\n--\ntools/include/io_uring/mini_liburing.h=55=struct io_uring {\n--\ntools/include/io_uring/mini_liburing.h-69-\ntools/include/io_uring/mini_liburing.h:70:static inline int io_uring_mmap(int fd, struct io_uring_params *p,\ntools/include/io_uring/mini_liburing.h-71-\t\t\t\tstruct io_uring_sq *sq, struct io_uring_cq *cq)\n--\ntools/include/io_uring/mini_liburing.h=139=static inline int io_uring_queue_init_params(unsigned int entries,\n--\ntools/include/io_uring/mini_liburing.h-149-\t\treturn fd;\ntools/include/io_uring/mini_liburing.h:150:\tret = io_uring_mmap(fd, p, \u0026ring-\u003esq, \u0026ring-\u003ecq);\ntools/include/io_uring/mini_liburing.h-151-\tif (!ret) {\n"
}

gemini-3.1-pro-preview

null

null

							input: 12090
							output: 130
							thoughts: 192
						

**Fuzzing Strategy for io_uring Memory Management**

Okay, so I'm looking at this patch and it's definitely a functional change related to memory mapping within io_uring. Specifically, we're dealing with the `io_uring_mmap` function, which handles mmap calls within the io_uring context. We've got `io_create_region` and `io_free_region` being used now whenever regions are created or released. This is a significant shift in how io_uring manages its memory accounting.

Given this, I'm thinking this is absolutely worth fuzzing. The changes introduce `struct io_region_account` and modify how memory is managed and freed. This means we've got new logic paths in these three functions, `io_create_region`, `io_free_region`, and `io_uring_mmap` that are potentially vulnerable. These are core kernel routines, so finding a bug here would be impactful.

Therefore, my strategy is simple: I'll flag this as `WorthFuzzing: true`, and concentrate my fuzzing efforts on those specific symbols: `io_create_region`, `io_free_region`, and `io_uring_mmap`. The obvious prerequisite is `EnableConfigs: IO_URING`, because if that isn't set, then the whole thing is irrelevant. Because of the memory handling aspect, this could be a fun and fruitful target. Let's get to work.

{
  "EnableConfigs": [
    "IO_URING"
  ],
  "FocusSymbols": [
    "io_create_region",
    "io_free_region",
    "io_uring_mmap"
  ],
  "Reasoning": "The patch modifies memory accounting and mapping logic for io_uring regions, introducing `struct io_region_account` and changing how memory is accounted and freed. This affects `io_create_region`, `io_free_region`, and `io_uring_mmap`. These are reachable core kernel logic and should be fuzzed.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "IO_URING"
  ],
  "FocusSymbols": [
    "io_create_region",
    "io_free_region",
    "io_uring_mmap"
  ],
  "Reasoning": "The patch modifies memory accounting and mapping logic for io_uring regions, introducing `struct io_region_account` and changing how memory is accounted and freed. This affects `io_create_region`, `io_free_region`, and `io_uring_mmap`. These are reachable core kernel logic and should be fuzzed.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch introduces a new internal structure `io_region_account` to track memory accounting for io_uring memory regions across VMA lifecycles. The structure is allocated internally and all its fields (`refs`, `user`, `nr_pages`) are explicitly initialized before use. No new data structures are copied to userspace, and no uninitialized memory is exposed or used in control flow. The changes primarily address memory accounting and object lifecycles, where any potential bugs (such as use-after-free or memory leaks) would be effectively caught by KASAN or standard kernel memory leak detectors. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

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

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

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

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

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

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

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


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

For your convenience, here is the diff of the changes:
commit 3512947c0d36024efd5119feb5941d5aa0dfd430
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 16 07:29:33 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
index 87151a5b62c1b..6feb7ee3440fd 100644
--- a/include/linux/io_uring_types.h
+++ b/include/linux/io_uring_types.h
@@ -94,11 +94,14 @@ struct io_hash_table {
 	unsigned		hash_bits;
 };
 
+struct io_region_account;
+
 struct io_mapped_region {
 	struct page		**pages;
 	void			*ptr;
 	unsigned		nr_pages;
 	unsigned		flags;
+	struct io_region_account	*account;
 };
 
 /*
diff --git a/io_uring/memmap.c b/io_uring/memmap.c
index 23e8a85111bca..ca28a9429c168 100644
--- a/io_uring/memmap.c
+++ b/io_uring/memmap.c
@@ -4,6 +4,8 @@
 #include <linux/errno.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
+#include <linux/refcount.h>
+#include <linux/sched/user.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
 #include <linux/io_uring.h>
@@ -88,6 +90,52 @@ enum {
 	IO_REGION_F_SINGLE_REF			= 4,
 };
 
+struct io_region_account {
+	refcount_t refs;
+	struct user_struct *user;
+	unsigned long nr_pages;
+};
+
+static struct io_region_account *
+io_region_account_alloc(struct user_struct *user, unsigned long nr_pages)
+{
+	struct io_region_account *account;
+	int ret;
+
+	if (!user)
+		return NULL;
+
+	account = kmalloc_obj(*account, GFP_KERNEL_ACCOUNT);
+	if (!account)
+		return ERR_PTR(-ENOMEM);
+
+	ret = __io_account_mem(user, nr_pages);
+	if (ret) {
+		kfree(account);
+		return ERR_PTR(ret);
+	}
+
+	refcount_set(&account->refs, 1);
+	account->user = get_uid(user);
+	account->nr_pages = nr_pages;
+	return account;
+}
+
+static void io_region_account_get(struct io_region_account *account)
+{
+	if (account)
+		refcount_inc(&account->refs);
+}
+
+static void io_region_account_put(struct io_region_account *account)
+{
+	if (account && refcount_dec_and_test(&account->refs)) {
+		__io_unaccount_mem(account->user, account->nr_pages);
+		free_uid(account->user);
+		kfree(account);
+	}
+}
+
 void io_free_region(struct user_struct *user, struct io_mapped_region *mr)
 {
 	if (mr->pages) {
@@ -105,8 +153,12 @@ void io_free_region(struct user_struct *user, struct io_mapped_region *mr)
 	}
 	if ((mr->flags & IO_REGION_F_VMAP) && mr->ptr)
 		vunmap(mr->ptr);
-	if (mr->nr_pages && user)
+	if (mr->account) {
+		WARN_ON_ONCE(mr->account->user != user);
+		io_region_account_put(mr->account);
+	} else if (mr->nr_pages && user) {
 		__io_unaccount_mem(user, mr->nr_pages);
+	}
 
 	memset(mr, 0, sizeof(*mr));
 }
@@ -188,7 +240,8 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
 	int nr_pages, ret;
 	u64 end;
 
-	if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages))
+	if (WARN_ON_ONCE(mr->pages || mr->ptr || mr->nr_pages ||
+			 mr->account))
 		return -EFAULT;
 	if (memchr_inv(&reg->__resv, 0, sizeof(reg->__resv)))
 		return -EINVAL;
@@ -207,10 +260,23 @@ int io_create_region(struct io_ring_ctx *ctx, struct io_mapped_region *mr,
 		return -EOVERFLOW;
 
 	nr_pages = reg->size >> PAGE_SHIFT;
-	if (ctx->user) {
-		ret = __io_account_mem(ctx->user, nr_pages);
-		if (ret)
+	if (reg->flags & IORING_MEM_REGION_TYPE_USER) {
+		if (ctx->user) {
+			ret = __io_account_mem(ctx->user, nr_pages);
+			if (ret)
+				return ret;
+		}
+	} else {
+		/*
+		 * Kernel-allocated pages can outlive their active region through
+		 * userspace mappings.
+		 */
+		mr->account = io_region_account_alloc(ctx->user, nr_pages);
+		if (IS_ERR(mr->account)) {
+			ret = PTR_ERR(mr->account);
+			mr->account = NULL;
 			return ret;
+		}
 	}
 	mr->nr_pages = nr_pages;
 
@@ -281,15 +347,41 @@ static void *io_uring_validate_mmap_request(struct file *file, loff_t pgoff)
 
 #ifdef CONFIG_MMU
 
+static void io_region_vm_open(struct vm_area_struct *vma)
+{
+	io_region_account_get(vma->vm_private_data);
+}
+
+static void io_region_vm_close(struct vm_area_struct *vma)
+{
+	io_region_account_put(vma->vm_private_data);
+}
+
+static const struct vm_operations_struct io_region_vm_ops = {
+	.open = io_region_vm_open,
+	.close = io_region_vm_close,
+};
+
 static int io_region_mmap(struct io_ring_ctx *ctx,
 			  struct io_mapped_region *mr,
 			  struct vm_area_struct *vma,
 			  unsigned max_pages)
 {
 	unsigned long nr_pages = min(mr->nr_pages, max_pages);
+	int ret;
 
 	vm_flags_set(vma, VM_DONTEXPAND);
-	return vm_insert_pages(vma, vma->vm_start, mr->pages, &nr_pages);
+	ret = vm_insert_pages(vma, vma->vm_start, mr->pages, &nr_pages);
+	if (!ret && mr->account) {
+		/*
+		 * Accounting deliberately remains at region granularity when
+		 * this VMA maps only part of the region.
+		 */
+		vma->vm_private_data = mr->account;
+		vma->vm_ops = &io_region_vm_ops;
+		vma->vm_ops->open(vma);
+	}
+	return ret;
 }
 
 __cold int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
@@ -379,6 +471,8 @@ static void io_uring_nommu_vm_close(struct vm_area_struct *vma)
 
 	for (index = vma->vm_start; index < vma->vm_end; index += PAGE_SIZE)
 		put_page(virt_to_page((void *) index));
+
+	io_region_account_put(vma->vm_private_data);
 }
 
 static const struct vm_operations_struct io_uring_nommu_vm_ops = {
@@ -411,6 +505,8 @@ int io_uring_mmap(struct file *file, struct vm_area_struct *vma)
 	for (i = 0; i < region->nr_pages; i++)
 		get_page(region->pages[i]);
 
+	vma->vm_private_data = region->account;
+	io_region_account_get(region->account);
 	vma->vm_ops = &io_uring_nommu_vm_ops;
 	return 0;
 }

gemini-3.1-pro-preview

null

null

							input: 4037
							output: 162
							thoughts: 1442
						

**io_uring Memory Accounting Fix: No Uninitialized Memory Risk**

Okay, so I'm looking at this patch for `io_uring/memmap.c`. It's a pretty straightforward addition for memory management. The core of it is the introduction of this `io_region_account` struct.  It's meant to track the memory accounting for those `io_mapped_region` regions. I see the fields: a reference count (`refs`), the `user` who owns the memory, and the number of pages (`nr_pages`).  It looks like it's allocated using `kmalloc_obj`, which I suspect is just a macro for `kmalloc` with some flags, likely `GFP_KERNEL_ACCOUNT`... yep, that's what it looks like.  It's important that this struct contains a `refcount` as a potential concurrency issue could exist.

Right, so the patch allocates this `io_region_account` and carefully initializes *all* its fields – the refcount, the user, and the number of pages.  Then it links this account to the `io_mapped_region` struct (`mr->account`).  And, critically, it associates this account with the VMA (Virtual Memory Area) during `io_region_mmap`. The `vma->vm_private_data = mr->account;` line is what matters for the lifecycle management. The accounting is now properly tied to the VMA's lifetime.

The beauty is that this is *entirely* internal.  Nothing from this `io_region_account` struct is ever copied out to userspace. No new user-facing structs are created, or existing ones modified in a way that risks exposing uninitialized memory. This is all about the kernel's internal memory accounting.  My primary concern is always uninitialized memory, but this patch doesn't introduce any risk of that kind.  My thought is that the patch *corrects* a bug where kernel-allocated pages could outlive their associated memory region and, by extension, the user space mapping, and so the accounting would be incorrect.

Let me just double-check, because I want to be *absolutely* sure. The `io_region_account` and `io_mapped_region` structs themselves are internal. The `io_create_region` function uses a `struct io_mapped_region *mr`, which is also internal.  We're adding this `mr->account` and initializing it. No external structs are changed. There are no changes here that expose uninitialized memory. This patch is just memory accounting lifecycle management, that is, it is fixing a leak. KASAN would definitely catch use-after-free issues here, if any existed. KMSAN wouldn't apply here.

Okay, let's just do a quick scan of the code again, just to be thorough: Yup, `account` is a pointer, that is initialized. The `io_region_account_alloc` function initializes every field before returning the account. Good. Then in cleanup functions the `account` is de-referenced and zeroed. And finally a check ensures that the region has been initialized. Standard VMA operations are correctly called: `io_region_vm_open`.

I'm confident. There is no uninitialized memory being exposed to userspace, or used in control flow. This is a memory accounting fix. No need for KMSAN. The reasoning is that the new `io_region_account` struct tracks memory across VMA lifecycles and every field is initialized.

{
  "KMSANReasoning": "The patch introduces a new internal structure `io_region_account` to track memory accounting for io_uring memory regions across VMA lifecycles. The structure is allocated internally and all its fields (`refs`, `user`, `nr_pages`) are explicitly initialized before use. No new data structures are copied to userspace, and no uninitialized memory is exposed or used in control flow. The changes primarily address memory accounting and object lifecycles, where any potential bugs (such as use-after-free or memory leaks) would be effectively caught by KASAN or standard kernel memory leak detectors. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch introduces a new internal structure `io_region_account` to track memory accounting for io_uring memory regions across VMA lifecycles. The structure is allocated internally and all its fields (`refs`, `user`, `nr_pages`) are explicitly initialized before use. No new data structures are copied to userspace, and no uninitialized memory is exposed or used in control flow. The changes primarily address memory accounting and object lifecycles, where any potential bugs (such as use-after-free or memory leaks) would be effectively caught by KASAN or standard kernel memory leak detectors. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}