AI Trajectory

null

{
  "EnableConfigs": [
    "BRCMFMAC",
    "BRCMFMAC_USB",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "brcmf_cyw_external_auth"
  ],
  "Reasoning": "The patch fixes an uninitialized memory issue and adds missing PMKID copy in the Broadcom FullMAC WLAN driver's external authentication handler. The function is reachable via cfg80211 netlink commands when a virtual USB Broadcom device is emulated.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit 86eacbaa98e57dca4044dee416e75863b6cc6a31\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Jul 26 11:56:36 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c\nindex 873754be5174bc..2c59b5e57959c0 100644\n--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c\n+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c\n@@ -200,7 +200,7 @@ brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\n {\n \tstruct brcmf_if *ifp;\n \tstruct brcmf_pub *drvr;\n-\tstruct brcmf_auth_req_status_le auth_status;\n+\tstruct brcmf_auth_req_status_le auth_status = {};\n \tint ret = 0;\n \n \tbrcmf_dbg(TRACE, \"Enter\\n\");\n@@ -208,6 +208,8 @@ brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\n \tifp = netdev_priv(dev);\n \tdrvr = ifp-\u003edrvr;\n \tif (params-\u003estatus == WLAN_STATUS_SUCCESS) {\n+\t\tif (params-\u003epmkid)\n+\t\t\tmemcpy(auth_status.pmkid, params-\u003epmkid, WLAN_PMKID_LEN);\n \t\tauth_status.flags = cpu_to_le16(BRCMF_EXTAUTH_SUCCESS);\n \t} else {\n \t\tbphy_err(drvr, \"External authentication failed: status=%d\\n\",\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "BRCMFMAC",
    "BRCMFMAC_USB",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "brcmf_cyw_external_auth"
  ],
  "Reasoning": "The patch fixes an uninitialized memory issue and adds missing PMKID copy in the Broadcom FullMAC WLAN driver's external authentication handler. The function is reachable via cfg80211 netlink commands when a virtual USB Broadcom device is emulated.",
  "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 86eacbaa98e57dca4044dee416e75863b6cc6a31
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Jul 26 11:56:36 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c
index 873754be5174bc..2c59b5e57959c0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c
@@ -200,7 +200,7 @@ brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,
 {
 	struct brcmf_if *ifp;
 	struct brcmf_pub *drvr;
-	struct brcmf_auth_req_status_le auth_status;
+	struct brcmf_auth_req_status_le auth_status = {};
 	int ret = 0;
 
 	brcmf_dbg(TRACE, "Enter\n");
@@ -208,6 +208,8 @@ brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,
 	ifp = netdev_priv(dev);
 	drvr = ifp->drvr;
 	if (params->status == WLAN_STATUS_SUCCESS) {
+		if (params->pmkid)
+			memcpy(auth_status.pmkid, params->pmkid, WLAN_PMKID_LEN);
 		auth_status.flags = cpu_to_le16(BRCMF_EXTAUTH_SUCCESS);
 	} else {
 		bphy_err(drvr, "External authentication failed: status=%d\n",

gemini-3.1-pro-preview

null

null

							input: 2306
							output: 24
							thoughts: 243
						

**Analyzing a Driver Patch**

Okay, so I'm looking at a patch that's touching `drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c`. Specifically, the `brcmf_cyw_external_auth` function. It seems like it's addressing a potential issue with uninitialized memory or a missing PMKID copy. It initializes `auth_status` and then copies `params->pmkid` to it, but only if `params->pmkid` is not NULL. Makes sense, that's a pretty straightforward way to ensure we're handling the PMKID data correctly. This is tagged as a fix, so presumably this was a bug.

The driver in question here is `brcmfmac`, which is a Broadcom 802.11 wireless LAN driver. My initial thought is, how testable is this in a virtualized environment? Wireless drivers can be tricky since they usually rely on specific hardware, unless we're dealing with something like `mac80211_hwsim`. But wait a second, `brcmfmac` supports SDIO, USB, and PCIE! That opens up some interesting possibilities.

I know USB devices can be emulated, but usually that's through USB gadget or something with dummy_hcd. But, wait...syzkaller! I remember they have a virtual USB fuzzer, `vhci`. So, that means USB drivers are potentially fuzzable. I'm going to quickly check if `brcmfmac` has USB support, that's the key. If it does, this opens up a whole new avenue for fuzzing this specific patch.

{
  "Expression": "brcmf_cyw_external_auth"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=197=static int\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:198:brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-199-\t\t\tstruct cfg80211_external_auth_params *params)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=234=static void brcmf_cyw_get_cfg80211_ops(struct brcmf_pub *drvr)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-236-\tdrvr-\u003eops-\u003emgmt_tx = brcmf_cyw_mgmt_tx;\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:237:\tdrvr-\u003eops-\u003eexternal_auth = brcmf_cyw_external_auth;\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-238-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 3310
							output: 19
							thoughts: 19
						

Okay, here's my take on those thoughts, tailored for an expert audience:

**Considering `brcmfmac` Fuzzing via USB**

Alright, let's get down to brass tacks. The `brcmfmac` driver. Intriguing target, especially with its exposure to potentially untrusted data via USB. The thought that's bubbling up is, could we effectively fuzz the `brcmfmac` driver by leveraging a USB interface? This angle hasn't been explored nearly as often as testing over-the-air, and the nuance of potential hardware requirements is something to consider. What's the potential attack surface? Are there specific USB transfer types that would be most promising? The complexity of the host-side USB stack, the intricacies of the driver itself... this is going to be a fascinating challenge and it could be fruitful for discovering new vulnerabilities. Time to dig in and formulate a plan.

{
  "Expression": "config BRCMFMAC"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:1:config BRCMFMAC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-2-\ttristate \"Broadcom FullMAC WLAN driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-10-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:11:config BRCMFMAC_PROTO_BCDC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-12-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-13-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:14:config BRCMFMAC_PROTO_MSGBUF\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-15-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-16-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:17:config BRCMFMAC_SDIO\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-18-\tbool \"SDIO bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-28-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:29:config BRCMFMAC_USB\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-30-\tbool \"USB bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-39-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:40:config BRCMFMAC_PCIE\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-41-\tbool \"PCIE bus interface support for FullMAC driver\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 4152
							output: 51
							thoughts: 94
						

**Investigating the `BRCMFMAC_USB` Module**

Okay, so I've confirmed that `BRCMFMAC_USB` is a defined entity. Now, my next step is to examine `brcmf_cyw_external_auth` within `drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c`. My thinking is that since we're dealing with Broadcom Wi-Fi and its USB interface, `brcmf_cyw_external_auth` might provide some relevant insights. Is this function specific to CYW? My recollection is that CYW refers to the Cypress/Broadcom Wi-Fi implementation. Understanding this function's purpose within that context could shed light on the USB integration. Before I dive too deep into the function itself, let's just quickly check the dependencies of `BRCMFMAC_USB`. That way, I can ensure I have the appropriate context.

{
  "File": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\tconfig BRCMFMAC\n   2:\t\ttristate \"Broadcom FullMAC WLAN driver\"\n   3:\t\tdepends on CFG80211\n   4:\t\tselect BRCMUTIL\n   5:\t\thelp\n   6:\t\t  This module adds support for wireless adapters based on Broadcom\n   7:\t\t  FullMAC chipsets. It has to work with at least one of the bus\n   8:\t\t  interface support. If you choose to build a module, it'll be called\n   9:\t\t  brcmfmac.ko.\n  10:\t\n  11:\tconfig BRCMFMAC_PROTO_BCDC\n  12:\t\tbool\n  13:\t\n  14:\tconfig BRCMFMAC_PROTO_MSGBUF\n  15:\t\tbool\n  16:\t\n  17:\tconfig BRCMFMAC_SDIO\n  18:\t\tbool \"SDIO bus interface support for FullMAC driver\"\n  19:\t\tdepends on (MMC = y || MMC = BRCMFMAC)\n  20:\t\tdepends on BRCMFMAC\n  21:\t\tselect BRCMFMAC_PROTO_BCDC\n  22:\t\tselect FW_LOADER\n  23:\t\tdefault y\n  24:\t\thelp\n  25:\t\t  This option enables the SDIO bus interface support for Broadcom\n  26:\t\t  IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to\n  27:\t\t  use the driver for a SDIO wireless card.\n  28:\t\n  29:\tconfig BRCMFMAC_USB\n  30:\t\tbool \"USB bus interface support for FullMAC driver\"\n  31:\t\tdepends on (USB = y || USB = BRCMFMAC)\n  32:\t\tdepends on BRCMFMAC\n  33:\t\tselect BRCMFMAC_PROTO_BCDC\n  34:\t\tselect FW_LOADER\n  35:\t\thelp\n  36:\t\t  This option enables the USB bus interface support for Broadcom\n  37:\t\t  IEEE802.11n embedded FullMAC WLAN driver. Say Y if you want to\n  38:\t\t  use the driver for an USB wireless card.\n  39:\t\n  40:\tconfig BRCMFMAC_PCIE\n  41:\t\tbool \"PCIE bus interface support for FullMAC driver\"\n  42:\t\tdepends on BRCMFMAC\n  43:\t\tdepends on PCI\n  44:\t\tselect BRCMFMAC_PROTO_MSGBUF\n  45:\t\tselect FW_LOADER\n  46:\t\thelp\n  47:\t\t  This option enables the PCIE bus interface support for Broadcom\n  48:\t\t  IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to\n  49:\t\t  use the driver for an PCIE wireless card.\n  50:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 5207
							output: 24
							thoughts: 279
						

**Fuzzing the `brcmf_cyw_external_auth` Function**

Okay, so this patch is touching `brcmf_cyw_external_auth`. It's assigning this function to `drvr->ops->external_auth`, which I recognize as the `external_auth` operation in cfg80211. My immediate thought is, "fuzzable?" Absolutely. It's a functional change within a wireless driver, and crucially, it's exposed through netlink (nl80211). That makes it accessible, assuming the device registers with the kernel, of course.

The next question in my mind is, "can this device registration be triggered within syzkaller?" Ah, yes! Syzkaller leverages vhci (virtual USB) to emulate USB devices. If we can get it to emulate a Broadcom USB device, then the driver *should* probe and register with cfg80211. And if that happens, then we can hit that `external_auth` function via nl80211.

Now, before I get too carried away, I need to make sure we have the correct kernel configuration. Let's see...I'll need `BRCMFMAC` and `BRCMFMAC_USB` enabled, clearly. And, of course, `CFG80211`. Technically, `MAC80211` isn't strictly *required* for a FullMAC driver like this, but `CFG80211` is. Okay, good. That all seems straightforward enough.

Alright, time to revisit `brcmf_cyw_external_auth` and confirm the attack surface.

{
  "Expression": "brcmf_cyw_external_auth"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=197=static int\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:198:brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-199-\t\t\tstruct cfg80211_external_auth_params *params)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=234=static void brcmf_cyw_get_cfg80211_ops(struct brcmf_pub *drvr)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-236-\tdrvr-\u003eops-\u003emgmt_tx = brcmf_cyw_mgmt_tx;\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:237:\tdrvr-\u003eops-\u003eexternal_auth = brcmf_cyw_external_auth;\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-238-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 6242
							output: 31
							thoughts: 27
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Tracing the Function Call**

Alright, let's dive in. My immediate thought is, "where is `brcmf_cyw_get_cfg80211_ops` actually *used*?". I need to understand its context. This means I'm going to start digging into the codebase. I need to trace back from that function and see what's *calling* it. Is it a module initialization routine? Is it part of a control path for handling an event? Knowing the calling functions will immediately tell me what area of the wireless stack this is relevant to. I'm thinking I'll start with a `grep` or a similar tool to find all instances of this symbol being referenced, then analyze those calls more closely. From there, I can determine the operational context and what dependencies or constraints are at play. My experience tells me that this is probably a critical piece related to cfg80211 integration within the Broadcom driver, but seeing the call sites will be key to understanding the specific purpose. Let's start digging.

{
  "Expression": "brcmf_cyw_get_cfg80211_ops"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=198=brcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-233-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:234:static void brcmf_cyw_get_cfg80211_ops(struct brcmf_pub *drvr)\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-235-{\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=374=const struct brcmf_fwvid_ops brcmf_cyw_ops = {\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-377-\t.activate_events = brcmf_cyw_activate_events,\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:378:\t.get_cfg80211_ops = brcmf_cyw_get_cfg80211_ops,\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-379-\t.register_event_handlers = brcmf_cyw_register_event_handlers,\n"
}

gemini-3.1-pro-preview

null

null

							input: 6974
							output: 22
							thoughts: 34
						

Here's my take on those thoughts:

**Analyzing `brcmf_cyw_ops` Usage**

Okay, so I'm looking at something within `brcmf_cyw_ops`. My first step, as always, is to understand its scope. I need to figure out the context. It's clear that it's related to some broader operation, so I have to go deeper and pinpoint where `brcmf_cyw_ops` is actually *used*. Where are the calls? What functions are leveraging this? Understanding the call sites is key to understanding its purpose and impact. I need to trace this one down.

{
  "Expression": "brcmf_cyw_ops"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c=362=static void brcmf_cyw_register_event_handlers(struct brcmf_pub *drvr)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-373-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c:374:const struct brcmf_fwvid_ops brcmf_cyw_ops = {\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c-375-\t.set_sae_password = brcmf_cyw_set_sae_pwd,\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/module.c=12=static int __init brcmf_cyw_init(void)\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/module.c-14-\treturn brcmf_fwvid_register_vendor(BRCMF_FWVENDOR_CYW, THIS_MODULE,\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/module.c:15:\t\t\t\t\t   \u0026brcmf_cyw_ops);\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/module.c-16-}\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/vops.h-7-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/vops.h:8:extern const struct brcmf_fwvid_ops brcmf_cyw_ops;\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/vops.h:9:#define CYW_VOPS\t(\u0026brcmf_cyw_ops)\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/vops.h-10-\n"
}

gemini-3.1-pro-preview

null

null

							input: 7747
							output: 19
							thoughts: 57
						

Here's my summary, as the expert:

**Investigating the `brcmfmac` Driver's CYW Configuration**

Okay, so I'm looking at how the `brcmfmac` driver handles its vendors. Specifically, it seems `brcmf_cyw_ops` is registered as the vendor operations structure for `BRCMF_FWVENDOR_CYW`. That indicates this is the entry point for handling Broadcom CYW (likely meaning Cypress Wireless) firmware or hardware within the `brcmfmac` framework. This registration is a key starting point.

Now, I need to dig in a bit deeper. Given that it has its own `ops` structure, the next logical step is to check for *specific* configuration options, settings, or variations tailored specifically for CYW devices within the broader `brcmfmac` codebase. Are there special quirks, optimizations, or parameter overrides based on detecting this vendor ID? What routines handle firmware loading, hardware initialization or power management *uniquely* for CYW? Time to trace the code paths and see what custom handling is present.

{
  "Expression": "config BRCMFMAC"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:1:config BRCMFMAC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-2-\ttristate \"Broadcom FullMAC WLAN driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-10-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:11:config BRCMFMAC_PROTO_BCDC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-12-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-13-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:14:config BRCMFMAC_PROTO_MSGBUF\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-15-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-16-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:17:config BRCMFMAC_SDIO\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-18-\tbool \"SDIO bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-28-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:29:config BRCMFMAC_USB\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-30-\tbool \"USB bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-39-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:40:config BRCMFMAC_PCIE\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-41-\tbool \"PCIE bus interface support for FullMAC driver\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 8668
							output: 22
							thoughts: 13
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**CYW Configuration Check**

Alright, let's dive in. My immediate thought is to determine if there's a pre-existing configuration file, directive, or system setting specifically dedicated to the CYW (presumably a Broadcom Wi-Fi chipset or related hardware, given the context). It's always best to start with a configuration check. This will depend on the OS and system in question. Is it a standard Linux distribution? A custom embedded system? Knowing the platform is key.

My focus now is on understanding if there's an existing file or mechanism to set up parameters for the CYW. I would look for known configuration file paths, environment variables, or even a database. If I'm lucky, a quick `grep` or `find` might reveal a relevant file. More likely, I will have to consult the manufacturer's documentation. The goal is to avoid reinventing the wheel and to leverage any existing framework that might already be in place for managing CYW device parameters, such as power management settings, interface settings, regulatory domain etc. If that's the case, I need to know where I can view and edit these.

no matches

{
  "Expression": "config BRCMFMAC_CYW"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 8974
							output: 50
							thoughts: 30
						

Here's my analysis of the provided text, rendered as a first-person expert summary:

**Diving into the brcmfmac Makefile**

Okay, so we're starting with the `drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile`. Immediately, I know this is where the meat of the Broadcom wireless driver compilation resides for the brcmfmac driver. My mental checklist kicks in: I'm anticipating to see the typical Makefile elements: source file lists, object file generation rules, dependency definitions, inclusion paths, probably some architecture-specific sections, and hopefully well-defined variables for the kernel build environment. I expect to see flags, object generation, rules for kernel modules, and any architecture-specific requirements or configurations, as well as the modules that might get added as a result of that build. I'll be looking for optimization flags, debugging symbols, and, of course, the module name definition. I'll be paying close attention to any conditional compilation flags. Specifically, I'm going to scan for the common `$(CONFIG_BRCMFMAC)` guard – that will tell me if we're dealing with the standard build. This initial scan is about building a mental map of the driver's build process.

{
  "File": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: ISC\n   2:\t#\n   3:\t# Makefile fragment for Broadcom 802.11 Networking Device Driver\n   4:\t#\n   5:\t# Copyright (c) 2010 Broadcom Corporation\n   6:\t#\n   7:\t\n   8:\tccflags-y += \\\n   9:\t\t-I $(src) \\\n  10:\t\t-I $(src)/../include\n  11:\t\n  12:\tobj-$(CONFIG_BRCMFMAC) += brcmfmac.o\n  13:\tbrcmfmac-objs += \\\n  14:\t\t\tcfg80211.o \\\n  15:\t\t\tchip.o \\\n  16:\t\t\tfwil.o \\\n  17:\t\t\tfweh.o \\\n  18:\t\t\tp2p.o \\\n  19:\t\t\tproto.o \\\n  20:\t\t\tcommon.o \\\n  21:\t\t\tcore.o \\\n  22:\t\t\tfirmware.o \\\n  23:\t\t\tfwvid.o \\\n  24:\t\t\tfeature.o \\\n  25:\t\t\tbtcoex.o \\\n  26:\t\t\tvendor.o \\\n  27:\t\t\tpno.o \\\n  28:\t\t\txtlv.o\n  29:\tbrcmfmac-$(CONFIG_BRCMFMAC_PROTO_BCDC) += \\\n  30:\t\t\tbcdc.o \\\n  31:\t\t\tfwsignal.o\n  32:\tbrcmfmac-$(CONFIG_BRCMFMAC_PROTO_MSGBUF) += \\\n  33:\t\t\tcommonring.o \\\n  34:\t\t\tflowring.o \\\n  35:\t\t\tmsgbuf.o\n  36:\tbrcmfmac-$(CONFIG_BRCMFMAC_SDIO) += \\\n  37:\t\t\tsdio.o \\\n  38:\t\t\tbcmsdh.o\n  39:\tbrcmfmac-$(CONFIG_BRCMFMAC_USB) += \\\n  40:\t\t\tusb.o\n  41:\tbrcmfmac-$(CONFIG_BRCMFMAC_PCIE) += \\\n  42:\t\t\tpcie.o\n  43:\tbrcmfmac-$(CONFIG_BRCMDBG) += \\\n  44:\t\t\tdebug.o\n  45:\tbrcmfmac-$(CONFIG_BRCM_TRACING) += \\\n  46:\t\t\ttracepoint.o\n  47:\tbrcmfmac-$(CONFIG_OF) += \\\n  48:\t\t\tof.o\n  49:\tbrcmfmac-$(CONFIG_DMI) += \\\n  50:\t\t\tdmi.o\n  51:\tbrcmfmac-$(CONFIG_ACPI) += \\\n  52:\t\t\tacpi.o\n  53:\t\n  54:\tifeq ($(CONFIG_BRCMFMAC),m)\n  55:\tobj-m += wcc/\n  56:\tobj-m += cyw/\n  57:\tobj-m += bca/\n  58:\telse\n  59:\tbrcmfmac-$(CONFIG_BRCMFMAC) += wcc/core.o\n  60:\tbrcmfmac-$(CONFIG_BRCMFMAC) += cyw/core.o\n  61:\tbrcmfmac-$(CONFIG_BRCMFMAC) += bca/core.o\n  62:\tendif\n"
}

gemini-3.1-pro-preview

null

null

							input: 10173
							output: 53
							thoughts: 84
						

Okay, let me break this down.

**Diving into the Build System - `cyw/core.o` and `CONFIG_BRCMFMAC`**

Right, so `cyw/core.o` is always built when `CONFIG_BRCMFMAC` is turned on. Seems straightforward enough at first glance. But hang on, a slight wrinkle emerges. If `CONFIG_BRCMFMAC` is built as a module (`CONFIG_BRCMFMAC=m`), doesn't that imply that the `cyw/` directory containing `cyw/core.o` *also* becomes a separate module? That's the critical point I need to clarify. To be absolutely sure, I'd better double-check the build configuration for that directory directly. The obvious place to look is the `Makefile` itself, specifically in `drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/Makefile`. I need to confirm whether the build logic reflects this conditional modularization.

{
  "File": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/Makefile",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: ISC\n   2:\t#\n   3:\t# Copyright (c) 2022 Broadcom Corporation\n   4:\t\n   5:\tccflags-y += \\\n   6:\t\t-I $(src) \\\n   7:\t\t-I $(src)/.. \\\n   8:\t\t-I $(src)/../../include\n   9:\t\n  10:\tobj-m += brcmfmac-cyw.o\n  11:\tbrcmfmac-cyw-objs += \\\n  12:\t\t\tcore.o module.o\n"
}

gemini-3.1-pro-preview

null

null

							input: 10685
							output: 56
							thoughts: 266
						

**Analyzing the `brcmfmac-cyw.ko` Module and External Authentication**

Okay, so I see `brcmfmac-cyw.ko` is built, which is a good starting point. I need to understand how `brcmf_cyw_external_auth` in `cyw/core.c` works. I recall this function is reached via the `cfg80211` external authentication operation. That's the entry point. Now, let's see if there are any other configuration dependencies.

I see that `BRCMFMAC` and `BRCMFMAC_USB` are relevant to this module, which is important for things like fuzzing via virtual USB. Of course, `CFG80211` itself is also critical here. I should probably check the dependencies of `CFG80211`. It seems to optionally depend on `RFKILL` and `MAC80211`. However, I'm pretty sure `CFG80211` is usually enabled in syzkaller.

Let's look at `BRCMFMAC` in more detail. It depends on `CFG80211`. And `BRCMFMAC_USB` depends on `(USB = y || USB = BRCMFMAC)` and `BRCMFMAC`. So the key modules are `BRCMFMAC` and `BRCMFMAC_USB`. Alright, I've got a clearer picture of the dependencies, I should circle back and review `brcmf_cyw_external_auth` again with this context in mind.

{
  "File": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/cyw/core.c",
  "FirstLine": 190,
  "LineCount": 50
}

{
  "Contents": " 190:\t\tcfg80211_mgmt_tx_status(wdev, *cookie, buf, len, ack,\n 191:\t\t\t\t\tGFP_KERNEL);\n 192:\tfree:\n 193:\t\tkfree(mf_params);\n 194:\t\treturn err;\n 195:\t}\n 196:\t\n 197:\tstatic int\n 198:\tbrcmf_cyw_external_auth(struct wiphy *wiphy, struct net_device *dev,\n 199:\t\t\t\tstruct cfg80211_external_auth_params *params)\n 200:\t{\n 201:\t\tstruct brcmf_if *ifp;\n 202:\t\tstruct brcmf_pub *drvr;\n 203:\t\tstruct brcmf_auth_req_status_le auth_status = {};\n 204:\t\tint ret = 0;\n 205:\t\n 206:\t\tbrcmf_dbg(TRACE, \"Enter\\n\");\n 207:\t\n 208:\t\tifp = netdev_priv(dev);\n 209:\t\tdrvr = ifp-\u003edrvr;\n 210:\t\tif (params-\u003estatus == WLAN_STATUS_SUCCESS) {\n 211:\t\t\tif (params-\u003epmkid)\n 212:\t\t\t\tmemcpy(auth_status.pmkid, params-\u003epmkid, WLAN_PMKID_LEN);\n 213:\t\t\tauth_status.flags = cpu_to_le16(BRCMF_EXTAUTH_SUCCESS);\n 214:\t\t} else {\n 215:\t\t\tbphy_err(drvr, \"External authentication failed: status=%d\\n\",\n 216:\t\t\t\t params-\u003estatus);\n 217:\t\t\tauth_status.flags = cpu_to_le16(BRCMF_EXTAUTH_FAIL);\n 218:\t\t}\n 219:\t\n 220:\t\tmemcpy(auth_status.peer_mac, params-\u003ebssid, ETH_ALEN);\n 221:\t\tparams-\u003essid.ssid_len = min_t(u8, params-\u003essid.ssid_len,\n 222:\t\t\t\t\t      IEEE80211_MAX_SSID_LEN);\n 223:\t\tauth_status.ssid_len = cpu_to_le32(params-\u003essid.ssid_len);\n 224:\t\tmemcpy(auth_status.ssid, params-\u003essid.ssid, params-\u003essid.ssid_len);\n 225:\t\n 226:\t\tret = brcmf_fil_iovar_data_set(ifp, \"auth_status\", \u0026auth_status,\n 227:\t\t\t\t\t       sizeof(auth_status));\n 228:\t\tif (ret \u003c 0)\n 229:\t\t\tbphy_err(drvr, \"auth_status iovar failed: ret=%d\\n\", ret);\n 230:\t\n 231:\t\treturn ret;\n 232:\t}\n 233:\t\n 234:\tstatic void brcmf_cyw_get_cfg80211_ops(struct brcmf_pub *drvr)\n 235:\t{\n 236:\t\tdrvr-\u003eops-\u003emgmt_tx = brcmf_cyw_mgmt_tx;\n 237:\t\tdrvr-\u003eops-\u003eexternal_auth = brcmf_cyw_external_auth;\n 238:\t}\n 239:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 12239
							output: 19
							thoughts: 99
						

**Patch Analysis: `auth_status` and `pmkid`**

Okay, so this patch is all about tightening up some memory initialization, specifically within `auth_status`. It looks like we're also making sure that `pmkid` gets properly copied. Functionally, this is definitely a change that impacts the wireless authentication process, specifically targeting some vulnerabilities with uninitialized memory. `brcmf_cyw_external_auth` is the key symbol here, so that's where I need to focus my deeper analysis. Let's see if this solves the problem described in the associated ticket.

To confirm that, and to ensure I understand the build environment implications, I need to check the configurations. `BRCMFMAC`, `BRCMFMAC_USB`, and `CFG80211` are definitely relevant, given the driver's purpose. I need to be absolutely certain that those are the only relevant configs, however; it is likely that I'll need some additional context. I should double-check the dependencies of `BRCMFMAC` to be sure there isn't anything else in play here that I'm missing.

{
  "Expression": "config BRCMFMAC"
}

{
  "Output": "drivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:1:config BRCMFMAC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-2-\ttristate \"Broadcom FullMAC WLAN driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-10-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:11:config BRCMFMAC_PROTO_BCDC\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-12-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-13-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:14:config BRCMFMAC_PROTO_MSGBUF\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-15-\tbool\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-16-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:17:config BRCMFMAC_SDIO\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-18-\tbool \"SDIO bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-28-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:29:config BRCMFMAC_USB\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-30-\tbool \"USB bus interface support for FullMAC driver\"\n--\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-39-\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig:40:config BRCMFMAC_PCIE\ndrivers/net/wireless/broadcom/brcm80211/brcmfmac/Kconfig-41-\tbool \"PCIE bus interface support for FullMAC driver\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 13212
							output: 22
							thoughts: 15
						

Here's my attempt at summarizing the thought process, tailored for an expert audience:

**Diving into CFG80211 Dependencies**

Okay, so I need to get a handle on what's riding on `CFG80211` today. It's a critical piece, and any change I make needs to be meticulously planned, so let's start with a dependency analysis. Time to trace the lineage and see what this beast is connected to in the stack. What modules depend on this? What aspects of the networking stack are fundamentally tied to this? I need to understand all the downstream implications before I even consider making a tweak. It’s like surgery; you don't start cutting without knowing the patient's full anatomy. Let’s identify the potential ripple effects.

{
  "Expression": "config CFG80211"
}

{
  "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: 14334
							output: 33
							thoughts: 22
						

Here's my summary, as though I'm reading and processing the `net/wireless/Kconfig` file:

**Diving into the CFG80211 Configuration**

Okay, let's get into the heart of the matter – the `net/wireless/Kconfig` file, specifically around `CFG80211`. I need to understand how the configuration options related to wireless networking are structured and what dependencies are in play. My primary interest is always the architecture – how the modules fit together.

So, I'm scanning for `CFG80211`, likely searching for the `config` block that defines it. Right, here it is. It's marked as a core wireless networking component, which makes sense. I see it's an `tristate` which is useful. I should look for dependencies.

I see that `CFG80211` can be built as a module. That opens the door for runtime loading, which is good. Important for different use cases. I need to keep in mind, of course, that core components that are built-in require a reboot to update.

The dependencies here are always crucial. Anything that hinges on this? Okay, it's pretty self-contained, though it does depend on the kernel being built with support for the networking stack, which makes sense. I can probably skip over that one.
There's probably a lot of device drivers in the wider tree that hook into this configuration. I should probably have a look at those to better understand the relationships.
Alright, overall, the configuration seems well-defined and clearly structured. Now, I need to see how these configuration choices impact the code itself. Time to dive into the associated source files and see how those `ifdef` statements are used.

{
  "File": "net/wireless/Kconfig",
  "FirstLine": 17,
  "LineCount": 20
}

{
  "Contents": "  17:\tconfig CFG80211\n  18:\t\ttristate \"cfg80211 - wireless configuration API\"\n  19:\t\tdepends on RFKILL || !RFKILL\n  20:\t\tselect FW_LOADER\n  21:\t\tselect CRC32\n  22:\t\t# may need to update this when certificates are changed and are\n  23:\t\t# using a different algorithm, though right now they shouldn't\n  24:\t\t# (this is here rather than below to allow it to be a module)\n  25:\t\tselect CRYPTO_SHA256 if CFG80211_USE_KERNEL_REGDB_KEYS\n  26:\t\thelp\n  27:\t\t  cfg80211 is the Linux wireless LAN (802.11) configuration API.\n  28:\t\t  Enable this if you have a wireless device.\n  29:\t\n  30:\t\t  For more information refer to documentation on the wireless wiki:\n  31:\t\n  32:\t\t  https://wireless.wiki.kernel.org/en/developers/Documentation/cfg80211\n  33:\t\n  34:\t\t  When built as a module it will be called cfg80211.\n  35:\t\n  36:\tif CFG80211\n"
}

gemini-3.1-pro-preview

null

null

							input: 15102
							output: 126
							thoughts: 269
						

**My Analysis of Broadcom WLAN Driver Vulnerability**

Okay, so I'm looking at this Broadcom WLAN driver vulnerability and how to approach it for fuzzing. It seems the core dependencies are a bit tangled. I see that `CFG80211` hinges on `RFKILL` – either it's enabled or disabled, but it *must* be defined. Then, `BRCMFMAC` relies on `CFG80211`, naturally. So, just those two would mean I need `BRCMFMAC`, `BRCMFMAC_USB`, and `CFG80211` at a minimum.

Wait, `BRCMFMAC_USB` introduces a new dependency: `USB`. It needs `USB` to be set to 'y' or to equal `BRCMFMAC`. So, I'll need `USB` explicitly. I need to make sure I don't miss anything. Let's see... `BRCMFMAC`, `BRCMFMAC_USB`, `CFG80211`, and `USB` should be my configurations. Yes, that should cover it.

The interesting bit here is that `brcmf_cyw_external_auth` is reachable through `cfg80211` when emulating a Broadcom USB device. That's a good entry point. Given that this patch addresses an uninitialized memory issue and missing PMKID copy in the FullMAC driver's external authentication handler, it sounds definitely worth my time. I need to focus my fuzzing efforts on that `brcmf_cyw_external_auth` function. It seems to be the critical point, reachable via `cfg80211` netlink commands when a virtual USB Broadcom device is being used. That's my target, and that's how I'll frame my fuzzer.

{
  "EnableConfigs": [
    "BRCMFMAC",
    "BRCMFMAC_USB",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "brcmf_cyw_external_auth"
  ],
  "Reasoning": "The patch fixes an uninitialized memory issue and adds missing PMKID copy in the Broadcom FullMAC WLAN driver's external authentication handler. The function is reachable via cfg80211 netlink commands when a virtual USB Broadcom device is emulated.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "BRCMFMAC",
    "BRCMFMAC_USB",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "brcmf_cyw_external_auth"
  ],
  "Reasoning": "The patch fixes an uninitialized memory issue and adds missing PMKID copy in the Broadcom FullMAC WLAN driver's external authentication handler. The function is reachable via cfg80211 netlink commands when a virtual USB Broadcom device is emulated.",
  "WorthFuzzing": true
}