AI Trajectory

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__cpa_collapse_large_pages",
    "split_large_page",
    "__split_large_page"
  ],
  "Reasoning": "The patch modifies core x86 page attribute (CPA) manipulation functions to correctly free page tables using pte_free_kernel and pagetable_dtor_free instead of pagetable_free. These functions are reachable via set_memory_* APIs (e.g., used by BPF JIT, module loading) and should be fuzzed to ensure no memory leaks or use-after-free issues occur during large page splitting or collapsing.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 771d8c7c899884964688851eb0ef858ff769cf77\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Jul 22 07:54:28 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c\nindex 301fb9e77d91ba..078689aa7206f8 100644\n--- a/arch/x86/mm/pat/set_memory.c\n+++ b/arch/x86/mm/pat/set_memory.c\n@@ -439,7 +439,15 @@ static void __cpa_collapse_large_pages(struct cpa_data *cpa)\n \n \tlist_for_each_entry_safe(ptdesc, tmp, \u0026pgtables, pt_list) {\n \t\tlist_del(\u0026ptdesc-\u003ept_list);\n-\t\tpagetable_free(ptdesc);\n+\t\t/*\n+\t\t * Only early alloc'd direct map should not be flagged PG_table\n+\t\t * here and those shouldn't be collapsed. However be abundantly\n+\t\t * cautious and handle the !PG_table case too.\n+\t\t */\n+\t\tif (PageTable((ptdesc_page(ptdesc))))\n+\t\t\tpagetable_dtor_free(ptdesc);\n+\t\telse\n+\t\t\tpagetable_free(ptdesc);\n \t}\n }\n \n@@ -1138,11 +1146,10 @@ static void split_set_pte(struct cpa_data *cpa, pte_t *pte, unsigned long pfn,\n \n static int\n __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,\n-\t\t   struct ptdesc *ptdesc)\n+\t\t   pte_t *pbase)\n {\n \tunsigned long lpaddr, lpinc, ref_pfn, pfn, pfninc = 1;\n-\tstruct page *base = ptdesc_page(ptdesc);\n-\tpte_t *pbase = (pte_t *)page_address(base);\n+\tstruct page *base = virt_to_page(pbase);\n \tunsigned int i, level;\n \tpgprot_t ref_prot;\n \tbool nx, rw;\n@@ -1246,18 +1253,18 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,\n static int split_large_page(struct cpa_data *cpa, pte_t *kpte,\n \t\t\t    unsigned long address)\n {\n-\tstruct ptdesc *ptdesc;\n+\tpte_t *pte;\n \n \tif (!debug_pagealloc_enabled())\n \t\tspin_unlock(\u0026cpa_lock);\n-\tptdesc = pagetable_alloc(GFP_KERNEL, 0);\n+\tpte = pte_alloc_one_kernel(\u0026init_mm);\n \tif (!debug_pagealloc_enabled())\n \t\tspin_lock(\u0026cpa_lock);\n-\tif (!ptdesc)\n+\tif (!pte)\n \t\treturn -ENOMEM;\n \n-\tif (__split_large_page(cpa, kpte, address, ptdesc))\n-\t\tpagetable_free(ptdesc);\n+\tif (__split_large_page(cpa, kpte, address, pte))\n+\t\tpte_free_kernel(\u0026init_mm, pte);\n \n \treturn 0;\n }\n"
}

best-expensive

null

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__cpa_collapse_large_pages",
    "split_large_page",
    "__split_large_page"
  ],
  "Reasoning": "The patch modifies core x86 page attribute (CPA) manipulation functions to correctly free page tables using pte_free_kernel and pagetable_dtor_free instead of pagetable_free. These functions are reachable via set_memory_* APIs (e.g., used by BPF JIT, module loading) and should be fuzzed to ensure no memory leaks or use-after-free issues occur during large page splitting or collapsing.",
  "WorthFuzzing": true
}

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

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

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

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

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


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

For your convenience, here is the diff of the changes:
commit 771d8c7c899884964688851eb0ef858ff769cf77
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Jul 22 07:54:28 2026 +0000

    syz-cluster: applied patch under review

diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 301fb9e77d91ba..078689aa7206f8 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -439,7 +439,15 @@ static void __cpa_collapse_large_pages(struct cpa_data *cpa)
 
 	list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
 		list_del(&ptdesc->pt_list);
-		pagetable_free(ptdesc);
+		/*
+		 * Only early alloc'd direct map should not be flagged PG_table
+		 * here and those shouldn't be collapsed. However be abundantly
+		 * cautious and handle the !PG_table case too.
+		 */
+		if (PageTable((ptdesc_page(ptdesc))))
+			pagetable_dtor_free(ptdesc);
+		else
+			pagetable_free(ptdesc);
 	}
 }
 
@@ -1138,11 +1146,10 @@ static void split_set_pte(struct cpa_data *cpa, pte_t *pte, unsigned long pfn,
 
 static int
 __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
-		   struct ptdesc *ptdesc)
+		   pte_t *pbase)
 {
 	unsigned long lpaddr, lpinc, ref_pfn, pfn, pfninc = 1;
-	struct page *base = ptdesc_page(ptdesc);
-	pte_t *pbase = (pte_t *)page_address(base);
+	struct page *base = virt_to_page(pbase);
 	unsigned int i, level;
 	pgprot_t ref_prot;
 	bool nx, rw;
@@ -1246,18 +1253,18 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
 static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
 			    unsigned long address)
 {
-	struct ptdesc *ptdesc;
+	pte_t *pte;
 
 	if (!debug_pagealloc_enabled())
 		spin_unlock(&cpa_lock);
-	ptdesc = pagetable_alloc(GFP_KERNEL, 0);
+	pte = pte_alloc_one_kernel(&init_mm);
 	if (!debug_pagealloc_enabled())
 		spin_lock(&cpa_lock);
-	if (!ptdesc)
+	if (!pte)
 		return -ENOMEM;
 
-	if (__split_large_page(cpa, kpte, address, ptdesc))
-		pagetable_free(ptdesc);
+	if (__split_large_page(cpa, kpte, address, pte))
+		pte_free_kernel(&init_mm, pte);
 
 	return 0;
 }

gemini-3.1-pro-preview

null

null

							input: 2514
							output: 36
							thoughts: 323
						

**Analyzing a Page Table Optimization Patch**

Okay, so this patch is digging into `arch/x86/mm/pat/set_memory.c`. Immediately, my spidey senses are tingling because that file handles memory attribute changes on x86, critical stuff. I see it's modifying a few key functions: `__cpa_collapse_large_pages`, `split_large_page`, and `__split_large_page`.

Looking closer, the first change in `__cpa_collapse_large_pages` suggests a conditional check for the page table descriptor with `pagetable_dtor_free` being used as a replacement to `pagetable_free`. Then, it looks like `split_large_page` is being updated to use `pte_alloc_one_kernel` instead of `pagetable_alloc`, which is a change I can infer, as well as `pte_free_kernel` replacing `pagetable_free`. And finally `__split_large_page` now receives a `pte_t *pbase` instead of a `struct ptdesc *ptdesc`.

These internal functions are integral to the mechanisms behind the `set_memory_*` family of functions – the ones that control read-only, read-write, execute-never, and executable memory regions. That's a core functionality. Given the names of the affected functions and what they're doing, the changes are definitely functional and reachable, they are important.

Now, my next thought is about conditional compilation. Is this code always part of an x86 kernel build, or is it dependent on some configuration option? I'm betting that `CONFIG_X86_PAT` is involved, but I should double-check the `arch/x86/mm/pat/Makefile` to be sure. That's where the build rules would be defined.

{
  "Expression": "set_memory.o",
  "PathPrefix": "arch/x86/mm/pat/Makefile"
}

{
  "Output": "arch/x86/mm/pat/Makefile-2-\narch/x86/mm/pat/Makefile:3:obj-y\t\t\t\t:= set_memory.o memtype.o\narch/x86/mm/pat/Makefile-4-\n"
}

gemini-3.1-pro-preview

null

null

							input: 3342
							output: 44
							thoughts: 56
						

Okay, here's my interpretation of those thoughts, crafted with the understanding that I'm talking to a fellow expert:

**Investigating x86 Compilation and Large Page Handling**

Alright, I'm looking at this build and it looks like it's unconditionally compiling for x86. No surprises there, given the `obj-y` directive. My immediate thought is to delve into the large page handling on this x86 build, specifically focusing on how it deals with potential coalescing and splitting of large pages. I want to zero in on how these large page operations are implemented and, more importantly, how their use is conditioned, so I need to check the implementations of the `__cpa_collapse_large_pages` and `split_large_page` functions. These will be in `arch/x86/mm/pat/set_memory.c`, which makes the most sense. I'll take a look at the interplay of those.

{
  "Expression": "__cpa_collapse_large_pages",
  "PathPrefix": "arch/x86/mm/pat/set_memory.c"
}

{
  "Output": "arch/x86/mm/pat/set_memory.c=412=static int collapse_large_pages(unsigned long addr, struct list_head *pgtables);\narch/x86/mm/pat/set_memory.c-413-\narch/x86/mm/pat/set_memory.c:414:static void __cpa_collapse_large_pages(struct cpa_data *cpa)\narch/x86/mm/pat/set_memory.c-415-{\n--\narch/x86/mm/pat/set_memory.c=454=static void cpa_collapse_large_pages(struct cpa_data *cpa)\n--\narch/x86/mm/pat/set_memory.c-462-\tscoped_guard(mmap_write_lock, \u0026init_mm)\narch/x86/mm/pat/set_memory.c:463:\t\t__cpa_collapse_large_pages(cpa);\narch/x86/mm/pat/set_memory.c-464-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 3921
							output: 40
							thoughts: 11
						

Okay, here's my thought process, summarized as you requested:

**Checking `split_large_page`**

Alright, time to dive in. My immediate thought is to zero in on the `split_large_page` function or module. I need to refresh my memory on its role. Is it dealing with PDFs, images, text blocks, or something else entirely? What's the context? Is it part of a larger workflow? I'm going to quickly review its documentation, or the surrounding code if available, to understand its intended purpose and, importantly, what the anticipated "large page" entails. That clarification is key. Knowing the definition of "large" within this specific system is essential to avoid potential performance bottlenecks or unexpected behavior. Essentially, I need to pinpoint the functionality of `split_large_page` before I can evaluate anything further.

{
  "Expression": "split_large_page",
  "PathPrefix": "arch/x86/mm/pat/set_memory.c"
}

{
  "Output": "arch/x86/mm/pat/set_memory.c=932=static pgprot_t pgprot_clear_protnone_bits(pgprot_t prot)\n--\narch/x86/mm/pat/set_memory.c-948-\narch/x86/mm/pat/set_memory.c:949:static int __should_split_large_page(pte_t *kpte, unsigned long address,\narch/x86/mm/pat/set_memory.c-950-\t\t\t\t     struct cpa_data *cpa)\n--\narch/x86/mm/pat/set_memory.c-1095-\narch/x86/mm/pat/set_memory.c:1096:static int should_split_large_page(pte_t *kpte, unsigned long address,\narch/x86/mm/pat/set_memory.c-1097-\t\t\t\t   struct cpa_data *cpa)\n--\narch/x86/mm/pat/set_memory.c-1104-\tspin_lock(\u0026pgd_lock);\narch/x86/mm/pat/set_memory.c:1105:\tdo_split = __should_split_large_page(kpte, address, cpa);\narch/x86/mm/pat/set_memory.c-1106-\tspin_unlock(\u0026pgd_lock);\n--\narch/x86/mm/pat/set_memory.c=1111=static void split_set_pte(struct cpa_data *cpa, pte_t *pte, unsigned long pfn,\n--\narch/x86/mm/pat/set_memory.c-1118-\t/*\narch/x86/mm/pat/set_memory.c:1119:\t * If should_split_large_page() discovered an inconsistent mapping,\narch/x86/mm/pat/set_memory.c-1120-\t * remove the invalid protection in the split mapping.\n--\narch/x86/mm/pat/set_memory.c-1133-\t * fixed trivially as that would require to rescan the newly\narch/x86/mm/pat/set_memory.c:1134:\t * installed PMD mappings after returning from split_large_page()\narch/x86/mm/pat/set_memory.c-1135-\t * so an eventual further split can allocate the necessary PTE\n--\narch/x86/mm/pat/set_memory.c=1147=static int\narch/x86/mm/pat/set_memory.c:1148:__split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,\narch/x86/mm/pat/set_memory.c-1149-\t\t   pte_t *pbase)\n--\narch/x86/mm/pat/set_memory.c-1252-\narch/x86/mm/pat/set_memory.c:1253:static int split_large_page(struct cpa_data *cpa, pte_t *kpte,\narch/x86/mm/pat/set_memory.c-1254-\t\t\t    unsigned long address)\n--\narch/x86/mm/pat/set_memory.c-1265-\narch/x86/mm/pat/set_memory.c:1266:\tif (__split_large_page(cpa, kpte, address, pte))\narch/x86/mm/pat/set_memory.c-1267-\t\tpte_free_kernel(\u0026init_mm, pte);\n--\narch/x86/mm/pat/set_memory.c=1868=static int __change_page_attr(struct cpa_data *cpa, int primary)\n--\narch/x86/mm/pat/set_memory.c-1926-\t */\narch/x86/mm/pat/set_memory.c:1927:\tdo_split = should_split_large_page(kpte, address, cpa);\narch/x86/mm/pat/set_memory.c-1928-\t/*\n--\narch/x86/mm/pat/set_memory.c-1938-\t */\narch/x86/mm/pat/set_memory.c:1939:\terr = split_large_page(cpa, kpte, address);\narch/x86/mm/pat/set_memory.c-1940-\tif (!err)\n"
}

gemini-3.1-pro-preview

null

null

							input: 5310
							output: 34
							thoughts: 226
						

**Analyzing the Set Memory Functions in the x86 Architecture**

Okay, so I'm digging into how memory attributes are changed, specifically within the x86 architecture. It looks like the functions `split_large_page` and `__cpa_collapse_large_pages` are the internal workhorses within `arch/x86/mm/pat/set_memory.c`. They're called by `__change_page_attr` and `cpa_collapse_large_pages`, respectively. These in turn are invoked by `change_page_attr_set_clr`, which is the very heart of the `set_memory_*` family of functions.

Therefore, the key symbols I need to focus on are:
*   `split_large_page`
*   `__cpa_collapse_large_pages`
*   `__split_large_page`

Hold on a second. I just realized `__cpa_collapse_large_pages`, `split_large_page` and `__split_large_page` are all declared as static. Does that impact the analysis? Let me quickly consider this. *Can* we focus on these? Well, syzkaller *can* focus on static functions as long as they are present in the kernel image, which they should be. That's good to know. Now, are there any relevant kernel configurations here? I should check if `CONFIG_X86_PAT` is defined. This could be important for understanding the context.

{
  "Expression": "config X86_PAT",
  "PathPrefix": "arch/x86/Kconfig"
}

{
  "Output": "arch/x86/Kconfig=1691=config MTRR_SANITIZER_SPARE_REG_NR_DEFAULT\n--\narch/x86/Kconfig-1699-\narch/x86/Kconfig:1700:config X86_PAT\narch/x86/Kconfig-1701-\tdef_bool y\n"
}

gemini-3.1-pro-preview

null

null

							input: 5994
							output: 39
							thoughts: 286
						

**Analyzing the Page Table Descriptor Bug Fix**

Okay, so `X86_PAT` is defined as a boolean (`def_bool y`), meaning it's always enabled. That's a given. Now, let's consider `CONFIG_DEBUG_PAGEALLOC`. I see mentions of `debug_pagealloc_enabled()` in the code. I need to figure out if this patch *requires* `DEBUG_PAGEALLOC`. From a quick glance, the patch itself doesn't seem to depend on it. It seems to be cleaning up a bug – something about `pagetable_free` being incorrectly used where `pte_free_kernel` or `pagetable_dtor_free` should have been called.

The root of the issue appears to be around how page table descriptors (ptdesc) and page tables themselves are being freed. The patch seems to be addressing those incorrect calls in the `split_large_page` function. It looks like `pagetable_alloc` is being changed to `pte_alloc_one_kernel` and `pagetable_free` is being changed to `pte_free_kernel`. Additionally, in `__cpa_collapse_large_pages`, the code seems to be checking `PageTable(ptdesc_page(ptdesc))` and then calling either `pagetable_dtor_free(ptdesc)` or `pagetable_free(ptdesc)`.

I need to confirm there aren't any specific configuration options related to page table descriptors. No, it's a core memory management feature. And what about `set_memory.c`? Nope, that's also just core x86 memory management code.

Alright, now I need to dig into `set_memory.c` to see if there are any other configuration dependencies lurking there that might be relevant.

{
  "Expression": "#ifdef CONFIG_",
  "PathPrefix": "arch/x86/mm/pat/set_memory.c"
}

{
  "Output": "arch/x86/mm/pat/set_memory.c=79=static inline pgprot_t cachemode2pgprot(enum page_cache_mode pcm)\n--\narch/x86/mm/pat/set_memory.c-83-\narch/x86/mm/pat/set_memory.c:84:#ifdef CONFIG_PROC_FS\narch/x86/mm/pat/set_memory.c-85-static unsigned long direct_pages_count[PG_LEVEL_NUM];\n--\narch/x86/mm/pat/set_memory.c=139=static inline void collapse_page_count(int level) { }\n--\narch/x86/mm/pat/set_memory.c-141-\narch/x86/mm/pat/set_memory.c:142:#ifdef CONFIG_X86_CPA_STATISTICS\narch/x86/mm/pat/set_memory.c-143-\n--\narch/x86/mm/pat/set_memory.c=224=within(unsigned long addr, unsigned long start, unsigned long end)\n--\narch/x86/mm/pat/set_memory.c-228-\narch/x86/mm/pat/set_memory.c:229:#ifdef CONFIG_X86_64\narch/x86/mm/pat/set_memory.c-230-\n--\narch/x86/mm/pat/set_memory.c=298=static inline unsigned long fix_addr(unsigned long addr)\narch/x86/mm/pat/set_memory.c-299-{\narch/x86/mm/pat/set_memory.c:300:#ifdef CONFIG_X86_64\narch/x86/mm/pat/set_memory.c-301-\treturn (long)(addr \u003c\u003c 1) \u003e\u003e 1;\n--\narch/x86/mm/pat/set_memory.c=355=EXPORT_SYMBOL_GPL(clflush_cache_range);\narch/x86/mm/pat/set_memory.c-356-\narch/x86/mm/pat/set_memory.c:357:#ifdef CONFIG_ARCH_HAS_PMEM_API\narch/x86/mm/pat/set_memory.c-358-void arch_invalidate_pmem(void *addr, size_t size)\n--\narch/x86/mm/pat/set_memory.c=362=EXPORT_SYMBOL_GPL(arch_invalidate_pmem);\n--\narch/x86/mm/pat/set_memory.c-364-\narch/x86/mm/pat/set_memory.c:365:#ifdef CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION\narch/x86/mm/pat/set_memory.c-366-bool cpu_cache_has_invalidate_memregion(void)\n--\narch/x86/mm/pat/set_memory.c=505=static bool overlaps(unsigned long r1_start, unsigned long r1_end,\n--\narch/x86/mm/pat/set_memory.c-511-\narch/x86/mm/pat/set_memory.c:512:#ifdef CONFIG_PCI_BIOS\narch/x86/mm/pat/set_memory.c-513-/*\n--\narch/x86/mm/pat/set_memory.c=908=static void __set_pmd_pte(pte_t *kpte, unsigned long address, pte_t pte)\n--\narch/x86/mm/pat/set_memory.c-911-\tset_pte_atomic(kpte, pte);\narch/x86/mm/pat/set_memory.c:912:#ifdef CONFIG_X86_32\narch/x86/mm/pat/set_memory.c-913-\t{\n--\narch/x86/mm/pat/set_memory.c=1951=static int cpa_process_alias(struct cpa_data *cpa)\n--\narch/x86/mm/pat/set_memory.c-1986-\narch/x86/mm/pat/set_memory.c:1987:#ifdef CONFIG_X86_64\narch/x86/mm/pat/set_memory.c-1988-\t/*\n--\narch/x86/mm/pat/set_memory.c=2284=EXPORT_SYMBOL(set_memory_wb);\n--\narch/x86/mm/pat/set_memory.c-2286-/* Prevent speculative access to a page by marking it not-present */\narch/x86/mm/pat/set_memory.c:2287:#ifdef CONFIG_X86_64\narch/x86/mm/pat/set_memory.c-2288-int set_mce_nospec(unsigned long pfn)\n--\narch/x86/mm/pat/set_memory.c=2679=int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)\n--\narch/x86/mm/pat/set_memory.c-2686-\narch/x86/mm/pat/set_memory.c:2687:#ifdef CONFIG_DEBUG_PAGEALLOC\narch/x86/mm/pat/set_memory.c-2688-void __kernel_map_pages(struct page *page, int numpages, int enable)\n--\narch/x86/mm/pat/set_memory.c=2770=int __init kernel_unmap_pages_in_pgd(pgd_t *pgd, unsigned long address,\n--\narch/x86/mm/pat/set_memory.c-2802- */\narch/x86/mm/pat/set_memory.c:2803:#ifdef CONFIG_CPA_DEBUG\narch/x86/mm/pat/set_memory.c-2804-#include \"cpa-test.c\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 8236
							output: 152
							thoughts: 1485
						

**Fuzzing Analysis: X86 Core Page Table Collapse**

Okay, this patch is definitely worth fuzzing. It's touching core x86 code related to page table management, specifically large page collapsing and splitting. That's a prime target for finding memory corruption issues.

My immediate focus will be on these functions:

*   `__cpa_collapse_large_pages`
*   `split_large_page`
*   `__split_large_page`

I'm double-checking, just to be sure... yep, those are the modified functions.

Now, I need to think about relevant configurations. `CONFIG_X86_PAT` is a default "y", so that's covered. `CONFIG_DEBUG_PAGEALLOC` did catch my eye because of the conditional logic in `split_large_page`, but the crucial `pte_free_kernel` calls aren't dependent on it at runtime. It's a nice-to-have, and might expose different locking paths, but the core issue isn't gated by it. And, honestly, Syzkaller probably already has KASAN enabled, so the risk isn't that high. So I will leave `EnableConfigs` empty for now to avoid constraining the fuzzer.

The patch's core is about the correct freeing of page tables after they're collapsed or split. The fix addresses a bug where `pagetable_free` was used when `pte_free_kernel` or `pagetable_dtor_free` was needed. Given that this was likely found by syzbot, it's very relevant for fuzzing, because it means the code is not robust enough to deal with all kinds of states.

I checked for reachability from user space. The `set_memory_*` functions are often used by things like BPF JIT, module loading, kprobes, and ftrace, so it's definitely reachable.

**Here's the fuzzing setup I'll recommend:**

*   **WorthFuzzing: True**
*   **FocusSymbols:**
    *   `__cpa_collapse_large_pages`
    *   `split_large_page`
    *   `__split_large_page`
*   **EnableConfigs:** (Empty. No extra configuration needed)

This should be a fruitful target. The patch addresses a critical memory management issue, and is reachable from a wide variety of userspace actions.

{
  "EnableConfigs": [],
  "FocusSymbols": [
    "__cpa_collapse_large_pages",
    "split_large_page",
    "__split_large_page"
  ],
  "Reasoning": "The patch modifies core x86 page attribute (CPA) manipulation functions to correctly free page tables using pte_free_kernel and pagetable_dtor_free instead of pagetable_free. These functions are reachable via set_memory_* APIs (e.g., used by BPF JIT, module loading) and should be fuzzed to ensure no memory leaks or use-after-free issues occur during large page splitting or collapsing.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": null,
  "FocusSymbols": [
    "__cpa_collapse_large_pages",
    "split_large_page",
    "__split_large_page"
  ],
  "Reasoning": "The patch modifies core x86 page attribute (CPA) manipulation functions to correctly free page tables using pte_free_kernel and pagetable_dtor_free instead of pagetable_free. These functions are reachable via set_memory_* APIs (e.g., used by BPF JIT, module loading) and should be fuzzed to ensure no memory leaks or use-after-free issues occur during large page splitting or collapsing.",
  "WorthFuzzing": true
}