AI Trajectory

null

{
  "EnableConfigs": [
    "CFG80211",
    "MAC80211",
    "MAC80211_HWSIM"
  ],
  "FocusSymbols": [
    "cfg80211_process_wiphy_works"
  ],
  "Reasoning": "The patch modifies the runaway limit and changes a WARN_ON to a BUG() in cfg80211_process_wiphy_works. This is a functional change in the wireless core control path that can be reached via mac80211_hwsim.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 230936b6c8a6e52009f8cc60f2f1762faa34afe9\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Wed Jul 8 14:27:31 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/wireless/core.c b/net/wireless/core.c\nindex 3dcf63b04c41db..9a4d022f883838 100644\n--- a/net/wireless/core.c\n+++ b/net/wireless/core.c\n@@ -1256,7 +1256,7 @@ EXPORT_SYMBOL(wiphy_rfkill_start_polling);\n void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,\n \t\t\t\t  struct wiphy_work *end)\n {\n-\tunsigned int runaway_limit = 100;\n+\tunsigned int runaway_limit = 30000;\n \tunsigned long flags;\n \n \tlockdep_assert_held(\u0026rdev-\u003ewiphy.mtx);\n@@ -1278,8 +1278,8 @@ void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,\n \t\tif (wk == end)\n \t\t\tbreak;\n \n-\t\tif (WARN_ON(--runaway_limit == 0))\n-\t\t\tINIT_LIST_HEAD(\u0026rdev-\u003ewiphy_work_list);\n+\t\tif (--runaway_limit == 0)\n+\t\t\tBUG();\n \t}\n \tspin_unlock_irqrestore(\u0026rdev-\u003ewiphy_work_lock, flags);\n }\n"
}

gemini-3.1-pro-preview

null

{
  "EnableConfigs": [
    "CFG80211",
    "MAC80211",
    "MAC80211_HWSIM"
  ],
  "FocusSymbols": [
    "cfg80211_process_wiphy_works"
  ],
  "Reasoning": "The patch modifies the runaway limit and changes a WARN_ON to a BUG() in cfg80211_process_wiphy_works. This is a functional change in the wireless core control path that can be reached via mac80211_hwsim.",
  "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 230936b6c8a6e52009f8cc60f2f1762faa34afe9
Author: syz-cluster <triage@syzkaller.com>
Date:   Wed Jul 8 14:27:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/wireless/core.c b/net/wireless/core.c
index 3dcf63b04c41db..9a4d022f883838 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -1256,7 +1256,7 @@ EXPORT_SYMBOL(wiphy_rfkill_start_polling);
 void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,
 				  struct wiphy_work *end)
 {
-	unsigned int runaway_limit = 100;
+	unsigned int runaway_limit = 30000;
 	unsigned long flags;
 
 	lockdep_assert_held(&rdev->wiphy.mtx);
@@ -1278,8 +1278,8 @@ void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,
 		if (wk == end)
 			break;
 
-		if (WARN_ON(--runaway_limit == 0))
-			INIT_LIST_HEAD(&rdev->wiphy_work_list);
+		if (--runaway_limit == 0)
+			BUG();
 	}
 	spin_unlock_irqrestore(&rdev->wiphy_work_lock, flags);
 }

gemini-3.1-pro-preview

null

null

							input: 1984
							output: 32
							thoughts: 463
						

**Analyzing a `net/wireless/core.c` Patch**

Okay, so I'm looking at a patch that touches `net/wireless/core.c`, specifically the `cfg80211_process_wiphy_works` function. The code has been changed. My initial reaction is to think, "Is this fuzzable?" Since I'm an expert, I immediately zero in on the key parts. The `runaway_limit` has been bumped from 100 to 30000, which is interesting, but also a `WARN_ON` is now a `BUG()`. My gut says, "Yes, fuzz it! It's in the wireless core; changes here are often impactful."

But wait, I need to be precise. The instructions say to return `WorthFuzzing=false` under specific circumstances. Let me clarify if this is one of them. "Modifications to numeric constants or macros that *do not* functionally alter execution flow?" A change from `WARN_ON` to `BUG()` *definitely* alters the execution flow; that's a crash versus an attempt to continue. And the limit increase could expose the BUG more quickly, or make it more likely to occur. It's not a pure cosmetic change like logging or documentation. So, this change is not simply decorative.

The code snippet confirms this:

```c
-		if (WARN_ON(--runaway_limit == 0))
-			INIT_LIST_HEAD(&rdev->wiphy_work_list);
+		if (--runaway_limit == 0)
+			BUG();
```

The change is not merely cosmetic. It fundamentally changes kernel behavior, potentially leading to a crash instead of a more graceful recovery. I also need to check the configs for `net/wireless/core.c`. Let's confirm it uses `CONFIG_CFG80211`. Now I need to check `net/wireless/Makefile`. I will verify the makefile to confirm the config and its dependencies. This warrants further investigation. This patch is definitely worth fuzzing.

{
  "File": "net/wireless/Makefile",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0\n   2:\tobj-$(CONFIG_CFG80211) += cfg80211.o\n   3:\tobj-y += tests/\n   4:\t\n   5:\tobj-$(CONFIG_WEXT_CORE) += wext-core.o\n   6:\tobj-$(CONFIG_WEXT_PROC) += wext-proc.o\n   7:\tobj-$(CONFIG_WEXT_PRIV) += wext-priv.o\n   8:\t\n   9:\tcfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o\n  10:\tcfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o\n  11:\tcfg80211-y += michael-mic.o pmsr.o\n  12:\tcfg80211-$(CONFIG_OF) += of.o\n  13:\tcfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o\n  14:\tcfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o\n  15:\t\n  16:\tCFLAGS_trace.o := -I$(src)\n  17:\t\n  18:\tcfg80211-$(CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS) += shipped-certs.o\n  19:\tifneq ($(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR),)\n  20:\tcfg80211-y += extra-certs.o\n  21:\tendif\n  22:\t\n  23:\t$(obj)/shipped-certs.c: $(sort $(wildcard $(src)/certs/*.hex))\n  24:\t\t@$(kecho) \"  GEN     $@\"\n  25:\t\t$(Q)(echo '#include \"reg.h\"'; \\\n  26:\t\t  echo 'const u8 shipped_regdb_certs[] = {'; \\\n  27:\t\t  echo | cat - $^ ; \\\n  28:\t\t  echo '};'; \\\n  29:\t\t  echo 'unsigned int shipped_regdb_certs_len = sizeof(shipped_regdb_certs);'; \\\n  30:\t\t ) \u003e $@\n  31:\t\n  32:\t$(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR) \\\n  33:\t\t\t      $(sort $(wildcard $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR)/*.x509))\n  34:\t\t@$(kecho) \"  GEN     $@\"\n  35:\t\t$(Q)(set -e; \\\n  36:\t\t  allf=\"\"; \\\n  37:\t\t  for f in $^ ; do \\\n  38:\t\t      test -f $$f || continue;\\\n  39:\t\t      # similar to hexdump -v -e '1/1 \"0x%.2x,\" \"\\n\"' \\\n  40:\t\t      thisf=$$(od -An -v -tx1 \u003c $$f | \\\n  41:\t\t                   sed -e 's/ /\\n/g' | \\\n  42:\t\t                   sed -e 's/^[0-9a-f]\\+$$/\\0/;t;d' | \\\n  43:\t\t                   sed -e 's/^/0x/;s/$$/,/'); \\\n  44:\t\t      # file should not be empty - maybe command substitution failed? \\\n  45:\t\t      test ! -z \"$$thisf\";\\\n  46:\t\t      allf=$$allf$$thisf;\\\n  47:\t\t  done; \\\n  48:\t\t  ( \\\n  49:\t\t      echo '#include \"reg.h\"'; \\\n  50:\t\t      echo 'const u8 extra_regdb_certs[] = {'; \\\n  51:\t\t      echo \"$$allf\"; \\\n  52:\t\t      echo '};'; \\\n  53:\t\t      echo 'unsigned int extra_regdb_certs_len = sizeof(extra_regdb_certs);'; \\\n  54:\t\t  ) \u003e $@)\n  55:\t\n  56:\tclean-files += shipped-certs.c extra-certs.c\n"
}

gemini-3.1-pro-preview

null

null

							input: 4054
							output: 33
							thoughts: 83
						

**Analyzing the Reachability of `CFG80211`**

Okay, so I'm looking at `CFG80211` – the wireless configuration framework. The first question that pops into my head is whether this is something I can actually poke at in a controlled environment, especially since I'm often working with virtualized systems. Good news, it looks like `mac80211_hwsim` offers a great solution as it emulates the wireless hardware, which should give me access to the core wireless code.

Now, let's get specific. I need to focus on a particular function, and I believe `cfg80211_process_wiphy_works` is the right place to start. This is likely the entry point I'm after, where the magic really happens.

My next step is clear. I need to trace *where* this function gets called. Knowing the call sites will be crucial for understanding its role and how it's integrated within the larger `CFG80211` ecosystem.

{
  "Expression": "cfg80211_process_wiphy_works",
  "PathPrefix": ""
}

{
  "Output": "net/wireless/core.c=1254=EXPORT_SYMBOL(wiphy_rfkill_start_polling);\nnet/wireless/core.c-1255-\nnet/wireless/core.c:1256:void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,\nnet/wireless/core.c-1257-\t\t\t\t  struct wiphy_work *end)\n--\nnet/wireless/core.c=1287=void wiphy_unregister(struct wiphy *wiphy)\n--\nnet/wireless/core.c-1330-\t/* surely nothing is reachable now, clean up work */\nnet/wireless/core.c:1331:\tcfg80211_process_wiphy_works(rdev, NULL);\nnet/wireless/core.c-1332-\twiphy_unlock(\u0026rdev-\u003ewiphy);\n--\nnet/wireless/core.c=1907=void wiphy_work_flush(struct wiphy *wiphy, struct wiphy_work *work)\n--\nnet/wireless/core.c-1919-\tif (run)\nnet/wireless/core.c:1920:\t\tcfg80211_process_wiphy_works(rdev, work);\nnet/wireless/core.c-1921-}\n--\nnet/wireless/core.h=469=void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);\nnet/wireless/core.h:470:void cfg80211_process_wiphy_works(struct cfg80211_registered_device *rdev,\nnet/wireless/core.h-471-\t\t\t\t  struct wiphy_work *end);\n--\nnet/wireless/sysfs.c=94=static int wiphy_suspend(struct device *dev)\n--\nnet/wireless/sysfs.c-106-\t\tscoped_guard(wiphy, \u0026rdev-\u003ewiphy) {\nnet/wireless/sysfs.c:107:\t\t\tcfg80211_process_wiphy_works(rdev, NULL);\nnet/wireless/sysfs.c-108-\t\t\tif (rdev-\u003eops-\u003esuspend)\n--\nnet/wireless/sysfs.c-120-\t\tcfg80211_process_rdev_events(rdev);\nnet/wireless/sysfs.c:121:\t\tcfg80211_process_wiphy_works(rdev, NULL);\nnet/wireless/sysfs.c-122-\t\tif (rdev-\u003eops-\u003esuspend)\n"
}

gemini-3.1-pro-preview

null

null

							input: 5066
							output: 31
							thoughts: 222
						

**Fuzzing the `cfg80211_process_wiphy_works` Function**

Okay, so I'm looking at `cfg80211_process_wiphy_works`. It's called from `wiphy_unregister`, `wiphy_work_flush`, and `wiphy_suspend`, so yeah, it's definitely reachable. Seems like a functional change in the wireless core, so it's probably worth putting some fuzzing effort into this.

Right, what configs do I need to enable? The instruction says I need `CFG80211`, obviously. And then `MAC80211_HWSIM` to actually be able to test this in a virtual machine, since the kernel documentation says "to compile and test". Though, hang on... `MAC80211_HWSIM` isn't *strictly* required to *compile* the code, just to test it effectively. But the prompt specified "compile and test". So, good, I'm on the right track! The instruction said: "List of kernel config flags that must be explicitly enabled to compile and test the modified code." So I'm good on `CFG80211` and `MAC80211_HWSIM`.

Let's just quickly double-check those two in Kconfig to be absolutely sure.

{
  "Expression": "config MAC80211_HWSIM",
  "PathPrefix": ""
}

{
  "Output": "drivers/net/wireless/virtual/Kconfig:1:config MAC80211_HWSIM\ndrivers/net/wireless/virtual/Kconfig-2-\ttristate \"Simulated radio testing tool for mac80211\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 5687
							output: 28
							thoughts: 17
						

Here's my thought process, summarized as if I were considering the given prompt:

**Kconfig Dive into CFG80211**

Okay, so the prompt wants me to summarize my thoughts about checking `CFG80211` in Kconfig. Alright, that's straightforward enough. This is likely about configuring a Linux kernel, specifically the wireless networking subsystem, and `CFG80211` is the core of that. I need to make sure I understand the context, and how it relates to the user. Since the prompt is to provide a "fulsome" summary, I should be detailed, but not overly verbose. I assume the user is familiar with the basics, so I can go into some details.

My initial thought is that I should *look* at the Kconfig file related to `CFG80211`. I know it’s a configuration system used to build Linux kernels, so I'd open the relevant Kconfig files. Then I'd check the dependencies, the help text, and see how `CFG80211` is exposed. I'd need to consider if `CFG80211` is enabled by default, what other options or features are dependent on it, and what other modules may be affected if it's disabled. Is it a module, or built-in, or potentially both? Are there any specific options that need careful consideration in different use-cases? Is there anything new I need to be aware of? Are there any relevant changes I might need to take account of? I'll need to check the broader configuration structure around it to get a full picture. And finally, I should keep in mind that I'm considering it in the context of a prompt, so this entire process is hypothetical.

{
  "Expression": "config CFG80211",
  "PathPrefix": ""
}

{
  "Output": "net/wireless/Kconfig=14=config WEXT_PRIV\n--\nnet/wireless/Kconfig-16-\nnet/wireless/Kconfig:17:config CFG80211\nnet/wireless/Kconfig-18-\ttristate \"cfg80211 - wireless configuration API\"\n--\nnet/wireless/Kconfig=38=config NL80211_TESTMODE\n--\nnet/wireless/Kconfig-51-\nnet/wireless/Kconfig:52:config CFG80211_DEVELOPER_WARNINGS\nnet/wireless/Kconfig-53-\tbool \"enable developer warnings\"\n--\nnet/wireless/Kconfig-67-\nnet/wireless/Kconfig:68:config CFG80211_CERTIFICATION_ONUS\nnet/wireless/Kconfig-69-\tbool \"cfg80211 certification onus\"\n--\nnet/wireless/Kconfig-88-\nnet/wireless/Kconfig:89:config CFG80211_REQUIRE_SIGNED_REGDB\nnet/wireless/Kconfig-90-\tbool \"require regdb signature\" if CFG80211_CERTIFICATION_ONUS\n--\nnet/wireless/Kconfig-98-\nnet/wireless/Kconfig:99:config CFG80211_USE_KERNEL_REGDB_KEYS\nnet/wireless/Kconfig-100-\tbool \"allow regdb keys shipped with the kernel\" if CFG80211_CERTIFICATION_ONUS\n--\nnet/wireless/Kconfig-110-\nnet/wireless/Kconfig:111:config CFG80211_EXTRA_REGDB_KEYDIR\nnet/wireless/Kconfig-112-\tstring \"additional regdb key directory\" if CFG80211_CERTIFICATION_ONUS\n--\nnet/wireless/Kconfig-121-\nnet/wireless/Kconfig:122:config CFG80211_REG_CELLULAR_HINTS\nnet/wireless/Kconfig-123-\tbool \"cfg80211 regulatory support for cellular base station hints\"\n--\nnet/wireless/Kconfig-134-\nnet/wireless/Kconfig:135:config CFG80211_REG_RELAX_NO_IR\nnet/wireless/Kconfig-136-\tbool \"cfg80211 support for NO_IR relaxation\"\n--\nnet/wireless/Kconfig-158-\nnet/wireless/Kconfig:159:config CFG80211_DEFAULT_PS\nnet/wireless/Kconfig-160-\tbool \"enable powersave by default\"\n--\nnet/wireless/Kconfig-168-\nnet/wireless/Kconfig:169:config CFG80211_DEBUGFS\nnet/wireless/Kconfig-170-\tbool \"cfg80211 DebugFS entries\"\n--\nnet/wireless/Kconfig-176-\nnet/wireless/Kconfig:177:config CFG80211_CRDA_SUPPORT\nnet/wireless/Kconfig-178-\tbool \"support CRDA\" if EXPERT\n--\nnet/wireless/Kconfig-186-\nnet/wireless/Kconfig:187:config CFG80211_WEXT\nnet/wireless/Kconfig-188-\tbool \"cfg80211 wireless extensions compatibility\"\n--\nnet/wireless/Kconfig-193-\nnet/wireless/Kconfig:194:config CFG80211_KUNIT_TEST\nnet/wireless/Kconfig-195-\ttristate \"KUnit tests for cfg80211\" if !KUNIT_ALL_TESTS\n"
}

gemini-3.1-pro-preview

null

null

							input: 7028
							output: 39
							thoughts: 364
						

**Analyzing the Wireless Core Changes**

Okay, so I'm looking at this patch and immediately, `CFG80211` and `MAC80211_HWSIM` are the configurations in play. My focus needs to be on `cfg80211_process_wiphy_works`. That's the modified function, definitely the key symbol here. Let's see... the patch only touches `cfg80211_process_wiphy_works`, confirming my initial thought. That function is *the* focus symbol, no doubt.

Now, a quick sanity check: is `cfg80211_process_wiphy_works` a hot-path function? Let's see... it's called during `wiphy_unregister`, `wiphy_work_flush`, and `wiphy_suspend`. Nope, not hot-path; those are all control-path functions. That makes sense; it’s perfect, actually, because that means it's handling the logic flow and isn't caught up in packet-processing overhead.

Okay, let me review the instructions to ensure I understand everything. "WorthFuzzing: true," great. "FocusSymbols: `cfg80211_process_wiphy_works`," check. "EnableConfigs: `CFG80211`, `MAC80211_HWSIM`," confirmed. The reasoning says the patch impacts the runaway limit, changes a `WARN_ON` to a `BUG()` in `cfg80211_process_wiphy_works`. It's a functional change in the wireless core control path, reachable via `mac80211_hwsim`.

One last thing, let's double check if `MAC80211_HWSIM` is enough or we need to enable `MAC80211`.

{
  "Expression": "depends on.*MAC80211",
  "PathPrefix": "drivers/net/wireless/virtual/Kconfig"
}

{
  "Output": "drivers/net/wireless/virtual/Kconfig=1=config MAC80211_HWSIM\ndrivers/net/wireless/virtual/Kconfig-2-\ttristate \"Simulated radio testing tool for mac80211\"\ndrivers/net/wireless/virtual/Kconfig:3:\tdepends on MAC80211\ndrivers/net/wireless/virtual/Kconfig-4-\thelp\n"
}

gemini-3.1-pro-preview

null

null

							input: 7950
							output: 41
							thoughts: 97
						

**Dependencies and Configuration**

Okay, so I'm looking at this and it's clear that `MAC80211_HWSIM` has a direct dependency on `MAC80211`. That makes sense; hardware simulation is built on the core MAC layer. Therefore, I need to be sure to include `MAC80211` when I'm configuring the system. Alright, let's add that to the EnableConfigs list: `["CFG80211", "MAC80211", "MAC80211_HWSIM"]`.

Hold on a second... right, of course. `CFG80211` is also a fundamental requirement for `MAC80211`. I knew that. Better make sure that's accounted for as well, just to be thorough.

{
  "Expression": "depends on.*CFG80211",
  "PathPrefix": "net/mac80211/Kconfig"
}

{
  "Output": "net/mac80211/Kconfig=2=config MAC80211\nnet/mac80211/Kconfig-3-\ttristate \"Generic IEEE 802.11 Networking Stack (mac80211)\"\nnet/mac80211/Kconfig:4:\tdepends on CFG80211\nnet/mac80211/Kconfig-5-\tselect CRYPTO\n--\nnet/mac80211/Kconfig=16=comment \"CFG80211 needs to be enabled for MAC80211\"\nnet/mac80211/Kconfig:17:\tdepends on CFG80211=n\nnet/mac80211/Kconfig-18-\n--\nnet/mac80211/Kconfig=88=config MAC80211_DEBUGFS\nnet/mac80211/Kconfig-89-\tbool \"Export mac80211 internals in DebugFS\"\nnet/mac80211/Kconfig:90:\tdepends on MAC80211 \u0026\u0026 CFG80211_DEBUGFS\nnet/mac80211/Kconfig-91-\thelp\n"
}

gemini-3.1-pro-preview

null

null

							input: 8583
							output: 135
							thoughts: 128
						

**Kernel Wireless Driver Module Design - Initial Assessment**

Okay, so I'm focusing on the wireless driver module design, specifically the relationship between the key components. Right, `MAC80211` definitely builds upon `CFG80211`. That dependency is fundamental, and it forms the basis of the modern kernel wireless stack. Therefore, `CFG80211`, `MAC80211`, and `MAC80211_HWSIM` are all likely useful areas to investigate.

Now, let me quickly confirm a specific detail about `cfg80211_process_wiphy_works`. I need to determine its scope. Is it static, or is it exposed for external use? A quick scan suggests it’s not static, and it's defined within `net/wireless/core.h`. That's good; it's a centrally located and probably critical symbol for my analysis.

Time to log what I've found. I'll call set-results and record my findings for now.

{
  "EnableConfigs": [
    "CFG80211",
    "MAC80211",
    "MAC80211_HWSIM"
  ],
  "FocusSymbols": [
    "cfg80211_process_wiphy_works"
  ],
  "Reasoning": "The patch modifies the runaway limit and changes a WARN_ON to a BUG() in cfg80211_process_wiphy_works. This is a functional change in the wireless core control path that can be reached via mac80211_hwsim.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "CFG80211",
    "MAC80211",
    "MAC80211_HWSIM"
  ],
  "FocusSymbols": [
    "cfg80211_process_wiphy_works"
  ],
  "Reasoning": "The patch modifies the runaway limit and changes a WARN_ON to a BUG() in cfg80211_process_wiphy_works. This is a functional change in the wireless core control path that can be reached via mac80211_hwsim.",
  "WorthFuzzing": true
}