AI Trajectory

Trajectory: (Expand/Collapse All)
Seq	Timestamp	Type	Name	Duration
0/0	2026/09/07 08:32	flow	patch-triage	1m Args: null Results: { "EnableConfigs": [ "MWIFIEX", "MWIFIEX_USB", "WLAN", "WLAN_VENDOR_MARVELL", "CFG80211", "USB" ], "FocusSymbols": [ "mwifiex_ret_wmm_get_status", "mwifiex_process_sta_cmdresp" ], "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.", "NeedsKMSAN": false, "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.", "WorthFuzzing": true }
1/1	2026/09/07 08:32	action	read-patch-diff	0m Args: null Results: { "PatchDiff": "commit 73b4040799d19dc62797c1bb9066af8d27359825\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Sep 7 08:32:06 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c\nindex 841505e83c7fd..febea68487e84 100644\n--- a/drivers/net/wireless/marvell/mwifiex/wmm.c\n+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c\n@@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\n \t\t\t\t tlv_wmm_qstatus-\u003eflow_required,\n \t\t\t\t tlv_wmm_qstatus-\u003edisabled);\n \n+\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n+\t\t\t\tbreak;\n \t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n \t\t\t\t\t\t\t queue_index];\n \t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n" }
2/1	2026/09/07 08:32	agent	patch-evaluator	1m Model: core Args: null Results: { "EnableConfigs": [ "MWIFIEX", "MWIFIEX_USB", "WLAN", "WLAN_VENDOR_MARVELL", "CFG80211", "USB" ], "FocusSymbols": [ "mwifiex_ret_wmm_get_status", "mwifiex_process_sta_cmdresp" ], "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.", "WorthFuzzing": true } Instruction: You are an expert Linux kernel maintainer and security engineer. Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller. IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in your workspace. Do NOT rely on internal assumptions. You must actively use your code access tools to inspect the actual source code, callers, and surrounding context. ================================================================================ 1. CORE TRIAGE PHILOSOPHY ================================================================================ The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs, and newly triggered assertions introduced by the patch series. - REACHABILITY IS THE PRIMARY GATE: Fuzzing can only discover bugs in code that can actually execute in standard virtualized environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap). If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed, regardless of whether it adds assertions or complex logic. - DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS: Patch authors routinely label changes as "cleanups", "refactorings", or state "No functional change intended". Do NOT take these claims at face value. Code refactorings that rearrange logic, introduce helper functions, or alter state management in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs. If reachable executable code is modified or refactored, it MUST be fuzzed. - NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED: When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON, VM_WARN_ON, BUG_ON, lockdep_assert) in reachable code paths, it enforces new or stricter invariants. Even if the author believes the invariant always holds, fuzzing is essential to verify whether an unusual sequence of operations can violate it. ================================================================================ 2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA) ================================================================================ Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories: - Non-kernel and non-executable changes: * Modifications to Documentation/, comments, or spelling fixes. * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/) that do not affect the compiled kernel image (vmlinux) or kernel modules. * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints that do not alter control flow or data structures. * Build system or Kconfig changes that do not alter compiled C logic. - Structurally unreachable hardware: * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed, ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU. - Unreachable execution paths: * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during physical PCI hot-unplug or manual sysfs driver unbinding. * Code paths exclusive to architectures other than the target architecture. ================================================================================ 3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA) ================================================================================ Return WorthFuzzing=true whenever the patch touches reachable executable code, including: - Core Subsystems: * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/), BPF, scheduler, core networking, VFS, or syscall handling. - Refactorings and Code Cleanups: * Any restructuring of reachable data structures, helper abstractions, or algorithm flows. - Runtime Assertions and Defensive Checks: * Any introduction or alteration of assertions (WARN_ON, VM_WARN_ON, BUG_ON, etc.) in reachable paths. - Reachable Drivers and Protocols: Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.). ================================================================================ 4. EXTRACTING FocusSymbols (PREVENTING DILUTION) ================================================================================ When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer: - AVOID UBIQUITOUS LIFECYCLE HOT-PATHS: Do NOT list generic, ubiquitous functions called by almost every program in the corpus (including, but not limited to: general memory allocators and deallocators, page fault and trap handlers, or core synchronization primitives; this is not an exhaustive list). Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused", which severely dilutes fuzzing effort away from the actual changes. - TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS: List functions that specifically implement the logic being added or altered, or direct API entrypoints for the subsystem feature under review. - HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h): Compiler-inlined static functions (such as static inlines in mm/.h or include/linux/.h) lack distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters. If the changes are primarily in static inline helpers, identify non-static, feature-specific caller functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers). ================================================================================ 5. IDENTIFYING EnableConfigs ================================================================================ Identify any specific CONFIG_ options required to properly compile and reach the modified code: - Inspect Kconfig files and #ifdef guards; do not make assumptions. - Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed. - Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4"). Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit 73b4040799d19dc62797c1bb9066af8d27359825 Author: syz-cluster <triage@syzkaller.com> Date: Mon Sep 7 08:32:06 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c index 841505e83c7fd..febea68487e84 100644 --- a/drivers/net/wireless/marvell/mwifiex/wmm.c +++ b/drivers/net/wireless/marvell/mwifiex/wmm.c @@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv, tlv_wmm_qstatus->flow_required, tlv_wmm_qstatus->disabled); + if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) + break; ac_status = &priv->wmm.ac_status[tlv_wmm_qstatus-> queue_index]; ac_status->disabled = tlv_wmm_qstatus->disabled;
3/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 2938 output: 38 thoughts: 417 Thoughts: Analyzing a Wireless Driver Patch for Fuzzing Potential Okay, let's break this down. My initial instinct is to assess this patch for fuzzing opportunities. I need to figure out if it's even worth fuzzing, and if so, how. First things first: let's read the patch. It seems like a relatively straightforward bounds check added in the `mwifiex_ret_wmm_get_status` function. The diff itself is simple, a check on `queue_index` within a WMM status update. Specifically the added check: `if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) break;`. This is looking for invalid queue indexes. Now, the real work begins. I need to understand where this driver, `mwifiex`, fits into the system. Is it a USB, SDIO, or PCIe driver? That directly impacts fuzzing strategy. Can I target it with USB fuzzing tools? Think syzkaller's USB raw gadget, USB emulation setups, or maybe even leverage mac80211_hwsim if I'm lucky. I need to dig into the `mwifiex` driver structure and Kconfig options to get this information. Based on the file path, `drivers/net/wireless/marvell/mwifiex/wmm.c`, it seems to be related to a Marvell wireless driver, but the exact interface protocol is still unclear. I'll need to use my tools to determine how the `mwifiex` driver is instantiated.
4/2	2026/09/07 08:32	tool	grepper	0m Args: { "Expression": "mwifiex", "PathPrefix": "drivers/net/wireless/marvell/mwifiex/Kconfig" } Results: { "Output": "drivers/net/wireless/marvell/mwifiex/Kconfig=2=config MWIFIEX\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-9-\t If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:10:\t mwifiex.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-11-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=12=config MWIFIEX_SDIO\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-22-\t If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:23:\t mwifiex_sdio.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-24-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=25=config MWIFIEX_PCIE\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-34-\t If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:35:\t mwifiex_pcie.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-36-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=37=config MWIFIEX_USB\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-45-\t If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:46:\t mwifiex_usb.\n" }
5/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 4170 output: 41 thoughts: 91 Thoughts: MWIFIEX_USB Support and Fuzzing Opportunities Okay, so `MWIFIEX_USB` is officially supported, which is fantastic! That opens up some interesting doors. Knowing that `mwifiex` has a USB interface driver (`drivers/net/wireless/marvell/mwifiex/usb.c`) is key. This means we've got a tangible avenue for fuzzing via USB emulation, syzkaller's USB raw gadget, or even vhci. This is significant; USB is generally well-understood from a fuzzing perspective, and the interface provides a defined entry point. Now, let's dive deeper. My next move is to investigate `MWIFIEX_USB` directly. I need to understand exactly how it’s configured and used. Beyond that, I want to trace the call paths to see how `mwifiex_ret_wmm_get_status` is reached. Mapping that out is essential for crafting targeted fuzzing harnesses. Knowing the entry points and the flow leading to that function gives me a roadmap for efficient and effective vulnerability discovery. This is where I'll be focusing my efforts.
6/2	2026/09/07 08:32	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/mwifiex/Kconfig", "FirstLine": 1, "LineCount": 50 } Results: { "Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig MWIFIEX\n 3:\t\ttristate \"Marvell WiFi-Ex Driver\"\n 4:\t\tdepends on CFG80211\n 5:\t\thelp\n 6:\t\t This adds support for wireless adapters based on Marvell\n 7:\t\t 802.11n/ac chipsets.\n 8:\t\n 9:\t\t If you choose to build it as a module, it will be called\n 10:\t\t mwifiex.\n 11:\t\n 12:\tconfig MWIFIEX_SDIO\n 13:\t\ttristate \"Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897/SD8977/SD8978/SD8987/SD8997\"\n 14:\t\tdepends on MWIFIEX \u0026\u0026 MMC\n 15:\t\tselect FW_LOADER\n 16:\t\tselect WANT_DEV_COREDUMP\n 17:\t\thelp\n 18:\t\t This adds support for wireless adapters based on Marvell\n 19:\t\t 8786/8787/8797/8887/8897/8977/8978/8987/8997 chipsets with\n 20:\t\t SDIO interface. SD8978 is also known as NXP IW416.\n 21:\t\n 22:\t\t If you choose to build it as a module, it will be called\n 23:\t\t mwifiex_sdio.\n 24:\t\n 25:\tconfig MWIFIEX_PCIE\n 26:\t\ttristate \"Marvell WiFi-Ex Driver for PCIE 8766/8897/8997\"\n 27:\t\tdepends on MWIFIEX \u0026\u0026 PCI\n 28:\t\tselect FW_LOADER\n 29:\t\tselect WANT_DEV_COREDUMP\n 30:\t\thelp\n 31:\t\t This adds support for wireless adapters based on Marvell\n 32:\t\t 8766/8897/8997 chipsets with PCIe interface.\n 33:\t\n 34:\t\t If you choose to build it as a module, it will be called\n 35:\t\t mwifiex_pcie.\n 36:\t\n 37:\tconfig MWIFIEX_USB\n 38:\t\ttristate \"Marvell WiFi-Ex Driver for USB8766/8797/8997\"\n 39:\t\tdepends on MWIFIEX \u0026\u0026 USB\n 40:\t\tselect FW_LOADER\n 41:\t\thelp\n 42:\t\t This adds support for wireless adapters based on Marvell\n 43:\t\t 8797/8997 chipset with USB interface.\n 44:\t\n 45:\t\t If you choose to build it as a module, it will be called\n 46:\t\t mwifiex_usb.\n" }
7/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 5307 output: 45 thoughts: 24 Thoughts: Here's my take on those thoughts, tailored for an expert audience: Diving into the WMM Status Retrieval Alright, let's get down to brass tacks. I need to understand the control flow and potential implications of this `mwifiex_ret_wmm_get_status` function. It's time to map its call graph. Specifically, I'm interested in the contexts that trigger this retrieval and, by extension, the conditions that might affect the WMM status. I'm already anticipating areas where subtle timing issues or race conditions might surface – these WMM-related functions tend to be sensitive. The goal here isn't just to see that it's called, but to build a mental model of why, and when it is called, from what state is it being called from? and what events triggered the calls? This will help pinpoint any issues in QoS management, power saving features, or inter-operation with other parts of the driver. Now, let's open that source...
8/2	2026/09/07 08:32	tool	grepper	0m Args: { "Expression": "mwifiex_ret_wmm_get_status", "PathPrefix": "drivers/net/wireless/marvell/mwifiex/" } Results: { "Output": "drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1212=int mwifiex_process_sta_cmdresp(struct mwifiex_private priv, u16 cmdresp_no,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1359-\tcase HostCmd_CMD_WMM_GET_STATUS:\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1360:\t\tret = mwifiex_ret_wmm_get_status(priv, resp);\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1361-\t\tbreak;\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.c=808=mwifiex_wmm_add_buf_txqueue(struct mwifiex_private priv,\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.c-909- /\ndrivers/net/wireless/marvell/mwifiex/wmm.c:910:int mwifiex_ret_wmm_get_status(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/wmm.c-911-\t\t\t const struct host_cmd_ds_command resp)\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.h=85=void mwifiex_wmm_setup_ac_downgrade(struct mwifiex_private priv);\ndrivers/net/wireless/marvell/mwifiex/wmm.h:86:int mwifiex_ret_wmm_get_status(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/wmm.h-87-\t\t\t const struct host_cmd_ds_command resp);\n" }
9/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 6065 output: 45 thoughts: 34 Thoughts: Here's my summary, as if I were thinking these thoughts: Analyzing the Marvell Wi-Fi WMM Implementation Okay, time to dive into this WMM implementation. I want to take a look at `drivers/net/wireless/marvell/mwifiex/wmm.c` – specifically, I'm focusing on the code around line 910 to 960. I need to get a better handle on how they're handling that specific part of the WMM functionality. Probably something about queue management or contention mechanisms, but I need to see it in action to know for sure. Let’s get to it. I want to see how Marvell's handling the WMM standard, and what potential optimizations or issues might be there.
10/2	2026/09/07 08:32	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/mwifiex/wmm.c", "FirstLine": 905, "LineCount": 70 } Results: { "Contents": " 905:\t * - Admission Control action frame TLVs\n 906:\t \n 907:\t This function parses the TLVs and then calls further specific functions\n 908:\t * to process any changes in the queue prioritize or state.\n 909:\t /\n 910:\tint mwifiex_ret_wmm_get_status(struct mwifiex_private priv,\n 911:\t\t\t\t const struct host_cmd_ds_command resp)\n 912:\t{\n 913:\t\tu8 curr = (u8 ) \u0026resp-\u003eparams.get_wmm_status;\n 914:\t\tuint16_t resp_len = le16_to_cpu(resp-\u003esize), tlv_len;\n 915:\t\tint mask = IEEE80211_WMM_IE_AP_QOSINFO_PARAM_SET_CNT_MASK;\n 916:\t\tbool valid = true;\n 917:\t\n 918:\t\tstruct mwifiex_ie_types_data tlv_hdr;\n 919:\t\tstruct mwifiex_ie_types_wmm_queue_status tlv_wmm_qstatus;\n 920:\t\tstruct ieee_types_wmm_parameter wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data ) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status )\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 940:\t\t\t\t\t \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 941:\t\t\t\t\t \"QSTATUS TLV: %d, %d, %d\\n\",\n 942:\t\t\t\t\t tlv_wmm_qstatus-\u003equeue_index,\n 943:\t\t\t\t\t tlv_wmm_qstatus-\u003eflow_required,\n 944:\t\t\t\t\t tlv_wmm_qstatus-\u003edisabled);\n 945:\t\n 946:\t\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n 947:\t\t\t\t\tbreak;\n 948:\t\t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n 949:\t\t\t\t\t\t\t\t queue_index];\n 950:\t\t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n 951:\t\t\t\tac_status-\u003eflow_required =\n 952:\t\t\t\t\t\t\ttlv_wmm_qstatus-\u003eflow_required;\n 953:\t\t\t\tac_status-\u003eflow_created = tlv_wmm_qstatus-\u003eflow_created;\n 954:\t\t\t\tbreak;\n 955:\t\n 956:\t\t\tcase WLAN_EID_VENDOR_SPECIFIC:\n 957:\t\t\t\t/\n 958:\t\t\t\t * Point the regular IEEE IE 2 bytes into the Marvell IE\n 959:\t\t\t\t * and setup the IEEE IE type and length byte fields\n 960:\t\t\t\t /\n 961:\t\n 962:\t\t\t\twmm_param_ie =\n 963:\t\t\t\t\t(struct ieee_types_wmm_parameter ) (curr +\n 964:\t\t\t\t\t\t\t\t\t 2);\n 965:\t\t\t\twmm_param_ie-\u003evend_hdr.len = (u8) tlv_len;\n 966:\t\t\t\twmm_param_ie-\u003evend_hdr.element_id =\n 967:\t\t\t\t\t\t\tWLAN_EID_VENDOR_SPECIFIC;\n 968:\t\n 969:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 970:\t\t\t\t\t \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 971:\t\t\t\t\t \"WMM Parameter Set Count: %d\\n\",\n 972:\t\t\t\t\t wmm_param_ie-\u003eqos_info_bitmap \u0026 mask);\n 973:\t\n 974:\t\t\t\tif (wmm_param_ie-\u003evend_hdr.len + 2 \u003e\n" }
11/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 7616 output: 29 thoughts: 459 Thoughts: Analyzing the Fuzzing Potential of a Bounds Check Okay, let's break this down. We've got a new patch that introduces a bounds check: `if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) break;`. The purpose of this seems pretty clear – to stop out-of-bounds access to `priv->wmm.ac_status`. But the question is: is this even reachable and therefore fuzzable? The triage guidelines make that the absolute priority. If it's unreachable in a standard virtualized environment (think GCE or QEMU with emulated devices), we're wasting our time. No fuzzing. My initial thought is that `mwifiex` has some potential. It's a USB driver, `MWIFIEX_USB`, and that’s interesting because it's emulatable using USB raw gadget or vHCI – Syzkaller specifically has USB raw gadget support for wifi drivers, and mwifiex is a USB wifi driver. This means we can inject firmware command responses through USB bulk or interrupt endpoints. That's a definite plus. Now, let's confirm the configurations and dependencies. I need to make sure `MWIFIEX_USB` is correctly configured and that all the right symbols are available. The Kconfig dependencies look like this: `MWIFIEX` depends on `CFG80211`, and `MWIFIEX_USB` depends on `MWIFIEX && USB` and selects `FW_LOADER`. That looks right, but let's do a quick grep search to confirm. I should scan `drivers/net/wireless/marvell/Kconfig` and `drivers/net/wireless/Kconfig` for `MWIFIEX` to make sure there are no other configurations or dependencies that might bite us later. Just to be thorough.
12/2	2026/09/07 08:32	tool	grepper	0m Args: { "Expression": "mwifiex", "PathPrefix": "drivers/net/wireless/" } Results: { "Output": "\nFull output is too long, showing 500 out of 18546 lines.\nUse more precise expression if possible.\n\ndrivers/net/wireless/marvell/Kconfig=16=source \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:17:source \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig-18-\n--\ndrivers/net/wireless/marvell/Makefile=4=obj-$(CONFIG_LIBERTAS_THINFIRM)\t+= libertas_tf/\ndrivers/net/wireless/marvell/Makefile:5:obj-$(CONFIG_MWIFIEX)\t+= mwifiex/\ndrivers/net/wireless/marvell/Makefile-6-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c=42=static u16\ndrivers/net/wireless/marvell/mwifiex/11ac.c:43:mwifiex_convert_mcsmap_to_maxrate(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-44-\t\t\t\t u8 bands, u16 mcs_map)\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-48-\tu32 usr_vht_cap_info = 0;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:49:\tstruct mwifiex_adapter adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-50-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c=85=static void\ndrivers/net/wireless/marvell/mwifiex/11ac.c:86:mwifiex_fill_vht_cap_info(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-87-\t\t\t struct ieee80211_vht_cap vht_cap, u8 bands)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-88-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:89:\tstruct mwifiex_adapter adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-90-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-98-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:99:void mwifiex_fill_vht_cap_tlv(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-100-\t\t\t struct ieee80211_vht_cap vht_cap, u8 bands)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-101-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:102:\tstruct mwifiex_adapter adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-103-\tu16 mcs_map_user, mcs_map_resp, mcs_map_result;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-106-\t/* Fill VHT cap info /\ndrivers/net/wireless/marvell/mwifiex/11ac.c:107:\tmwifiex_fill_vht_cap_info(priv, vht_cap, bands);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-108-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-128-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:129:\ttmp = mwifiex_convert_mcsmap_to_maxrate(priv, bands, mcs_map_result);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-130-\tvht_cap-\u003esupp_mcs.rx_highest = cpu_to_le16(tmp);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-150-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:151:\ttmp = mwifiex_convert_mcsmap_to_maxrate(priv, bands, mcs_map_result);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-152-\tvht_cap-\u003esupp_mcs.tx_highest = cpu_to_le16(tmp);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-156-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:157:int mwifiex_cmd_append_11ac_tlv(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c:158:\t\t\t struct mwifiex_bssdescriptor bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-159-\t\t\t u8 buffer)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-160-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:161:\tstruct mwifiex_ie_types_vhtcap vht_cap;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:162:\tstruct mwifiex_ie_types_oper_mode_ntf oper_ntf;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-163-\tstruct ieee_types_oper_mode_ntf ieee_oper_ntf;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:164:\tstruct mwifiex_ie_types_vht_oper vht_op;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:165:\tstruct mwifiex_adapter adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-166-\tu8 supp_chwd_set;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-176-\tif (bss_desc-\u003ebcn_vht_cap) {\ndrivers/net/wireless/marvell/mwifiex/11ac.c:177:\t\tvht_cap = (struct mwifiex_ie_types_vhtcap )buffer;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-178-\t\tmemset(vht_cap, 0, sizeof(vht_cap));\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-181-\t\t\t\tcpu_to_le16(sizeof(struct ieee80211_vht_cap));\ndrivers/net/wireless/marvell/mwifiex/11ac.c:182:\t\tmemcpy((u8 )vht_cap + sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11ac.c-183-\t\t (u8 )bss_desc-\u003ebcn_vht_cap,\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-185-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:186:\t\tmwifiex_fill_vht_cap_tlv(priv, \u0026vht_cap-\u003evht_cap,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-187-\t\t\t\t\t bss_desc-\u003ebss_band);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-194-\t\tif (priv-\u003ebss_mode == NL80211_IFTYPE_STATION) {\ndrivers/net/wireless/marvell/mwifiex/11ac.c:195:\t\t\tvht_op = (struct mwifiex_ie_types_vht_oper )buffer;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-196-\t\t\tmemset(vht_op, 0, sizeof(vht_op));\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-199-\t\t\tvht_op-\u003eheader.len = cpu_to_le16(sizeof(vht_op) -\ndrivers/net/wireless/marvell/mwifiex/11ac.c:200:\t\t\t\t sizeof(struct mwifiex_ie_types_header));\ndrivers/net/wireless/marvell/mwifiex/11ac.c-201-\t\t\tmemcpy((u8 )vht_op +\ndrivers/net/wireless/marvell/mwifiex/11ac.c:202:\t\t\t\tsizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11ac.c-203-\t\t\t (u8 )bss_desc-\u003ebcn_vht_oper,\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-252-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:253:int mwifiex_cmd_11ac_cfg(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-254-\t\t\t struct host_cmd_ds_command cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11ac.c:255:\t\t\t struct mwifiex_11ac_vht_cfg cfg)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-256-{\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-272-/* This function initializes the BlockACK setup information for given\ndrivers/net/wireless/marvell/mwifiex/11ac.c:273: * mwifiex_private structure for 11ac enabled networks.\ndrivers/net/wireless/marvell/mwifiex/11ac.c-274- /\ndrivers/net/wireless/marvell/mwifiex/11ac.c:275:void mwifiex_set_11ac_ba_params(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-276-{\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-293-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:294:bool mwifiex_is_bss_in_11ac_mode(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-295-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:296:\tstruct mwifiex_bssdescriptor bss_desc;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-297-\tstruct ieee80211_vht_operation vht_oper;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-310-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:311:u8 mwifiex_get_center_freq_index(struct mwifiex_private priv, u8 band,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-312-\t\t\t\t u32 pri_chan, u8 chan_bw)\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.h=14=enum vht_cfg_misc_config {\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.h-24-\ndrivers/net/wireless/marvell/mwifiex/11ac.h:25:int mwifiex_cmd_append_11ac_tlv(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h:26:\t\t\t\tstruct mwifiex_bssdescriptor bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-27-\t\t\t\tu8 *buffer);\ndrivers/net/wireless/marvell/mwifiex/11ac.h:28:int mwifiex_cmd_11ac_cfg(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-29-\t\t\t struct host_cmd_ds_command cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11ac.h:30:\t\t\t struct mwifiex_11ac_vht_cfg cfg);\ndrivers/net/wireless/marvell/mwifiex/11ac.h:31:void mwifiex_fill_vht_cap_tlv(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-32-\t\t\t struct ieee80211_vht_cap vht_cap, u8 bands);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-11-\ndrivers/net/wireless/marvell/mwifiex/11h.c:12:void mwifiex_init_11h_params(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-13-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-17-\ndrivers/net/wireless/marvell/mwifiex/11h.c:18:inline int mwifiex_is_11h_active(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-19-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c=25=static void\ndrivers/net/wireless/marvell/mwifiex/11h.c:26:mwifiex_11h_process_infra_join(struct mwifiex_private priv, u8 buffer,\ndrivers/net/wireless/marvell/mwifiex/11h.c:27:\t\t\t struct mwifiex_bssdescriptor bss_desc)\ndrivers/net/wireless/marvell/mwifiex/11h.c-28-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:29:\tstruct mwifiex_ie_types_header ie_header;\ndrivers/net/wireless/marvell/mwifiex/11h.c:30:\tstruct mwifiex_ie_types_pwr_capability cap;\ndrivers/net/wireless/marvell/mwifiex/11h.c:31:\tstruct mwifiex_ie_types_local_pwr_constraint constraint;\ndrivers/net/wireless/marvell/mwifiex/11h.c-32-\tstruct ieee80211_supported_band sband;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-38-\ndrivers/net/wireless/marvell/mwifiex/11h.c:39:\tradio_type = mwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11h.c-40-\tsband = priv-\u003ewdev.wiphy-\u003ebands[radio_type];\ndrivers/net/wireless/marvell/mwifiex/11h.c-41-\ndrivers/net/wireless/marvell/mwifiex/11h.c:42:\tcap = (struct mwifiex_ie_types_pwr_capability )buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-43-\tcap-\u003eheader.type = cpu_to_le16(WLAN_EID_PWR_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-48-\ndrivers/net/wireless/marvell/mwifiex/11h.c:49:\tconstraint = (struct mwifiex_ie_types_local_pwr_constraint )buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-50-\tconstraint-\u003eheader.type = cpu_to_le16(WLAN_EID_PWR_CONSTRAINT);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-55-\ndrivers/net/wireless/marvell/mwifiex/11h.c:56:\tie_header = (struct mwifiex_ie_types_header )buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-57-\tie_header-\u003etype = cpu_to_le16(TLV_TYPE_PASSTHROUGH);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-69-/* Enable or disable the 11h extensions in the firmware /\ndrivers/net/wireless/marvell/mwifiex/11h.c:70:int mwifiex_11h_activate(struct mwifiex_private priv, bool flag)\ndrivers/net/wireless/marvell/mwifiex/11h.c-71-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-77-\ndrivers/net/wireless/marvell/mwifiex/11h.c:78:\treturn mwifiex_send_cmd(priv, HostCmd_CMD_802_11_SNMP_MIB,\ndrivers/net/wireless/marvell/mwifiex/11h.c-79-\t\t\t\tHostCmd_ACT_GEN_SET, DOT11H_I, \u0026enable, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-87- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:88:void mwifiex_11h_process_join(struct mwifiex_private priv, u8 *buffer,\ndrivers/net/wireless/marvell/mwifiex/11h.c:89:\t\t\t struct mwifiex_bssdescriptor bss_desc)\ndrivers/net/wireless/marvell/mwifiex/11h.c-90-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-94-\t\t /\ndrivers/net/wireless/marvell/mwifiex/11h.c:95:\t\tmwifiex_11h_activate(priv, true);\ndrivers/net/wireless/marvell/mwifiex/11h.c-96-\t\tpriv-\u003estate_11h.is_11h_active = true;\ndrivers/net/wireless/marvell/mwifiex/11h.c-97-\t\tbss_desc-\u003ecap_info_bitmap \|= WLAN_CAPABILITY_SPECTRUM_MGMT;\ndrivers/net/wireless/marvell/mwifiex/11h.c:98:\t\tmwifiex_11h_process_infra_join(priv, buffer, bss_desc);\ndrivers/net/wireless/marvell/mwifiex/11h.c-99-\t} else {\ndrivers/net/wireless/marvell/mwifiex/11h.c-100-\t\t/ Deactivate 11h functions in the firmware /\ndrivers/net/wireless/marvell/mwifiex/11h.c:101:\t\tmwifiex_11h_activate(priv, false);\ndrivers/net/wireless/marvell/mwifiex/11h.c-102-\t\tpriv-\u003estate_11h.is_11h_active = false;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-110- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:111:void mwifiex_dfs_cac_work_queue(struct work_struct work)\ndrivers/net/wireless/marvell/mwifiex/11h.c-112-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-114-\tstruct delayed_work delayed_work = to_delayed_work(work);\ndrivers/net/wireless/marvell/mwifiex/11h.c:115:\tstruct mwifiex_private priv =\ndrivers/net/wireless/marvell/mwifiex/11h.c:116:\t\t\tcontainer_of(delayed_work, struct mwifiex_private,\ndrivers/net/wireless/marvell/mwifiex/11h.c-117-\t\t\t\t dfs_cac_work);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-120-\tif (priv-\u003ewdev.links[0].cac_started) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:121:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-122-\t\t\t \"CAC timer finished; No radar detected\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-131- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:132:int mwifiex_cmd_issue_chan_report_request(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-133-\t\t\t\t\t struct host_cmd_ds_command cmd,\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-136-\tstruct host_cmd_ds_chan_rpt_req cr_req = \u0026cmd-\u003eparams.chan_rpt_req;\ndrivers/net/wireless/marvell/mwifiex/11h.c:137:\tstruct mwifiex_radar_params radar_params = (void )data_buf;\ndrivers/net/wireless/marvell/mwifiex/11h.c-138-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-149-\tif (radar_params-\u003ecac_time_ms)\ndrivers/net/wireless/marvell/mwifiex/11h.c:150:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-151-\t\t\t \"11h: issuing DFS Radar check for channel=%d\\n\",\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-153-\telse\ndrivers/net/wireless/marvell/mwifiex/11h.c:154:\t\tmwifiex_dbg(priv-\u003eadapter, MSG, \"cancelling CAC\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c-155-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-158-\ndrivers/net/wireless/marvell/mwifiex/11h.c:159:int mwifiex_stop_radar_detection(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-160-\t\t\t\t struct cfg80211_chan_def chandef)\ndrivers/net/wireless/marvell/mwifiex/11h.c-161-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:162:\tstruct mwifiex_radar_params radar_params;\ndrivers/net/wireless/marvell/mwifiex/11h.c-163-\ndrivers/net/wireless/marvell/mwifiex/11h.c:164:\tmemset(\u0026radar_params, 0, sizeof(struct mwifiex_radar_params));\ndrivers/net/wireless/marvell/mwifiex/11h.c-165-\tradar_params.chandef = chandef;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-167-\ndrivers/net/wireless/marvell/mwifiex/11h.c:168:\treturn mwifiex_send_cmd(priv, HostCmd_CMD_CHAN_REPORT_REQUEST,\ndrivers/net/wireless/marvell/mwifiex/11h.c-169-\t\t\t\tHostCmd_ACT_GEN_SET, 0, \u0026radar_params, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-174- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:175:void mwifiex_abort_cac(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-176-{\ndrivers/net/wireless/marvell/mwifiex/11h.c-177-\tif (priv-\u003ewdev.links[0].cac_started) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:178:\t\tif (mwifiex_stop_radar_detection(priv, \u0026priv-\u003edfs_chandef))\ndrivers/net/wireless/marvell/mwifiex/11h.c:179:\t\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-180-\t\t\t\t \"failed to stop CAC in FW\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c:181:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-182-\t\t\t \"Aborting delayed work for CAC.\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-193- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:194:int mwifiex_11h_handle_chanrpt_ready(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-195-\t\t\t\t struct sk_buff skb)\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-197-\tstruct host_cmd_ds_chan_rpt_event rpt_event;\ndrivers/net/wireless/marvell/mwifiex/11h.c:198:\tstruct mwifiex_ie_types_chan_rpt_data rpt;\ndrivers/net/wireless/marvell/mwifiex/11h.c-199-\tu16 event_len, tlv_len;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-205-\tif (le32_to_cpu(rpt_event-\u003eresult) != HostCmd_RESULT_OK) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:206:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-207-\t\t\t \"Error in channel report event\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-210-\ndrivers/net/wireless/marvell/mwifiex/11h.c:211:\twhile (event_len \u003e= sizeof(struct mwifiex_ie_types_header)) {\ndrivers/net/wireless/marvell/mwifiex/11h.c-212-\t\trpt = (void )\u0026rpt_event-\u003etlvbuf;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-217-\t\t\tif (rpt-\u003emap.radar) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:218:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-219-\t\t\t\t\t \"RADAR Detected on channel %d!\\n\",\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-238-/ Handler for radar detected event from FW./\ndrivers/net/wireless/marvell/mwifiex/11h.c:239:int mwifiex_11h_handle_radar_detected(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-240-\t\t\t\t struct sk_buff skb)\ndrivers/net/wireless/marvell/mwifiex/11h.c-241-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:242:\tstruct mwifiex_radar_det_event rdr_event;\ndrivers/net/wireless/marvell/mwifiex/11h.c-243-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-245-\ndrivers/net/wireless/marvell/mwifiex/11h.c:246:\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-247-\t\t \"radar detected; indicating kernel\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c:248:\tif (mwifiex_stop_radar_detection(priv, \u0026priv-\u003edfs_chandef))\ndrivers/net/wireless/marvell/mwifiex/11h.c:249:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-250-\t\t\t \"Failed to stop CAC in FW\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-252-\t\t\t GFP_KERNEL);\ndrivers/net/wireless/marvell/mwifiex/11h.c:253:\tmwifiex_dbg(priv-\u003eadapter, MSG, \"regdomain: %d\\n\",\ndrivers/net/wireless/marvell/mwifiex/11h.c-254-\t\t rdr_event-\u003ereg_domain);\ndrivers/net/wireless/marvell/mwifiex/11h.c:255:\tmwifiex_dbg(priv-\u003eadapter, MSG, \"radar detection type: %d\\n\",\ndrivers/net/wireless/marvell/mwifiex/11h.c-256-\t\t rdr_event-\u003edet_type);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-265- /\ndrivers/net/wireless/marvell/mwifiex/11h.c:266:void mwifiex_dfs_chan_sw_work_queue(struct work_struct work)\ndrivers/net/wireless/marvell/mwifiex/11h.c-267-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:268:\tstruct mwifiex_uap_bss_param bss_cfg;\ndrivers/net/wireless/marvell/mwifiex/11h.c-269-\tstruct delayed_work delayed_work = to_delayed_work(work);\ndrivers/net/wireless/marvell/mwifiex/11h.c:270:\tstruct mwifiex_private priv =\ndrivers/net/wireless/marvell/mwifiex/11h.c:271:\t\t\tcontainer_of(delayed_work, struct mwifiex_private,\ndrivers/net/wireless/marvell/mwifiex/11h.c-272-\t\t\t\t dfs_chan_sw_work);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-275-\tif (!bss_cfg-\u003ebeacon_period) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:276:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-277-\t\t\t \"channel switch: AP already stopped\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-280-\ndrivers/net/wireless/marvell/mwifiex/11h.c:281:\tmwifiex_uap_set_channel(priv, bss_cfg, priv-\u003edfs_chandef);\ndrivers/net/wireless/marvell/mwifiex/11h.c-282-\ndrivers/net/wireless/marvell/mwifiex/11h.c:283:\tif (mwifiex_config_start_uap(priv, bss_cfg)) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:284:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-285-\t\t\t \"Failed to start AP after channel switch\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-288-\ndrivers/net/wireless/marvell/mwifiex/11h.c:289:\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-290-\t\t \"indicating channel switch completion to kernel\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-24- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:25:int mwifiex_fill_cap_info(struct mwifiex_private priv, u8 radio_type,\ndrivers/net/wireless/marvell/mwifiex/11n.c-26-\t\t\t struct ieee80211_ht_cap ht_cap)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-32-\tif (WARN_ON_ONCE(!sband)) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:33:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR, \"Invalid radio type!\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-34-\t\treturn -EINVAL;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-69- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:70:static struct mwifiex_tx_ba_stream_tbl \ndrivers/net/wireless/marvell/mwifiex/11n.c:71:mwifiex_get_ba_status(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:72:\t\t enum mwifiex_ba_status ba_status)\ndrivers/net/wireless/marvell/mwifiex/11n.c-73-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:74:\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-75-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-95- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:96:int mwifiex_ret_11n_delba(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-97-\t\t\t struct host_cmd_ds_command resp)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-99-\tint tid;\ndrivers/net/wireless/marvell/mwifiex/11n.c:100:\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-101-\tstruct host_cmd_ds_11n_delba del_ba = \u0026resp-\u003eparams.del_ba;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-105-\tif (del_ba-\u003edel_result == BA_RESULT_SUCCESS) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:106:\t\tmwifiex_del_ba_tbl(priv, tid, del_ba-\u003epeer_mac_addr,\ndrivers/net/wireless/marvell/mwifiex/11n.c-107-\t\t\t\t TYPE_DELBA_SENT,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-109-\ndrivers/net/wireless/marvell/mwifiex/11n.c:110:\t\ttx_ba_tbl = mwifiex_get_ba_status(priv, BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-111-\t\tif (tx_ba_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c:112:\t\t\tmwifiex_send_addba(priv, tx_ba_tbl-\u003etid,\ndrivers/net/wireless/marvell/mwifiex/11n.c-113-\t\t\t\t\t tx_ba_tbl-\u003era);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-120-\ndrivers/net/wireless/marvell/mwifiex/11n.c:121:\t\tmwifiex_create_ba_tbl(priv, del_ba-\u003epeer_mac_addr, tid,\ndrivers/net/wireless/marvell/mwifiex/11n.c-122-\t\t\t\t BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-123-\ndrivers/net/wireless/marvell/mwifiex/11n.c:124:\t\ttx_ba_tbl = mwifiex_get_ba_status(priv, BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-125-\ndrivers/net/wireless/marvell/mwifiex/11n.c-126-\t\tif (tx_ba_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c:127:\t\t\tmwifiex_del_ba_tbl(priv, tx_ba_tbl-\u003etid, tx_ba_tbl-\u003era,\ndrivers/net/wireless/marvell/mwifiex/11n.c-128-\t\t\t\t\t TYPE_DELBA_SENT, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-141- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:142:int mwifiex_ret_11n_addba_req(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-143-\t\t\t struct host_cmd_ds_command resp)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-146-\tstruct host_cmd_ds_11n_addba_rsp add_ba_rsp = \u0026resp-\u003eparams.add_ba_rsp;\ndrivers/net/wireless/marvell/mwifiex/11n.c:147:\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c:148:\tstruct mwifiex_ra_list_tbl ra_list;\ndrivers/net/wireless/marvell/mwifiex/11n.c-149-\tu16 block_ack_param_set = le16_to_cpu(add_ba_rsp-\u003eblock_ack_param_set);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-156-\ndrivers/net/wireless/marvell/mwifiex/11n.c:157:\ttid_down = mwifiex_wmm_downgrade_tid(priv, tid);\ndrivers/net/wireless/marvell/mwifiex/11n.c:158:\tra_list = mwifiex_wmm_get_ralist_node(priv, tid_down, add_ba_rsp-\u003e\ndrivers/net/wireless/marvell/mwifiex/11n.c-159-\t\tpeer_mac_addr);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-164-\t\t}\ndrivers/net/wireless/marvell/mwifiex/11n.c:165:\t\tmwifiex_del_ba_tbl(priv, tid, add_ba_rsp-\u003epeer_mac_addr,\ndrivers/net/wireless/marvell/mwifiex/11n.c-166-\t\t\t\t TYPE_DELBA_SENT, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-172-\ndrivers/net/wireless/marvell/mwifiex/11n.c:173:\ttx_ba_tbl = mwifiex_get_ba_tbl(priv, tid, add_ba_rsp-\u003epeer_mac_addr);\ndrivers/net/wireless/marvell/mwifiex/11n.c-174-\tif (tx_ba_tbl) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:175:\t\tmwifiex_dbg(priv-\u003eadapter, EVENT, \"info: BA stream complete\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-176-\t\ttx_ba_tbl-\u003eba_status = BA_SETUP_COMPLETE;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-187-\t} else {\ndrivers/net/wireless/marvell/mwifiex/11n.c:188:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR, \"BA stream not created\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-189-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-201- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:202:int mwifiex_cmd_recfg_tx_buf(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-203-\t\t\t struct host_cmd_ds_command cmd, int cmd_action,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-214-\tcase HostCmd_ACT_GEN_SET:\ndrivers/net/wireless/marvell/mwifiex/11n.c:215:\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\ndrivers/net/wireless/marvell/mwifiex/11n.c-216-\t\t\t \"cmd: set tx_buf=%d\\n\", buf_size);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-234- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:235:int mwifiex_cmd_amsdu_aggr_ctrl(struct host_cmd_ds_command cmd,\ndrivers/net/wireless/marvell/mwifiex/11n.c-236-\t\t\t\tint cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11n.c:237:\t\t\t\tstruct mwifiex_ds_11n_amsdu_aggr_ctrl aa_ctrl)\ndrivers/net/wireless/marvell/mwifiex/11n.c-238-{\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-267- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:268:int mwifiex_cmd_11n_cfg(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-269-\t\t\tstruct host_cmd_ds_command cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11n.c:270:\t\t\tstruct mwifiex_ds_11n_tx_cfg txcfg)\ndrivers/net/wireless/marvell/mwifiex/11n.c-271-{\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c=298=int\ndrivers/net/wireless/marvell/mwifiex/11n.c:299:mwifiex_cmd_append_11n_tlv(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:300:\t\t\t struct mwifiex_bssdescriptor bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11n.c-301-\t\t\t u8 *buffer)\ndrivers/net/wireless/marvell/mwifiex/11n.c-302-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:303:\tstruct mwifiex_ie_types_htcap ht_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c:304:\tstruct mwifiex_ie_types_htinfo ht_info;\ndrivers/net/wireless/marvell/mwifiex/11n.c:305:\tstruct mwifiex_ie_types_chan_list_param_set chan_list;\ndrivers/net/wireless/marvell/mwifiex/11n.c:306:\tstruct mwifiex_ie_types_2040bssco bss_co_2040;\ndrivers/net/wireless/marvell/mwifiex/11n.c:307:\tstruct mwifiex_ie_types_extcap ext_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c-308-\tint ret_len = 0;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-315-\ndrivers/net/wireless/marvell/mwifiex/11n.c:316:\tradio_type = mwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-317-\tsband = priv-\u003ewdev.wiphy-\u003ebands[radio_type];\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-319-\tif (bss_desc-\u003ebcn_ht_cap) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:320:\t\tht_cap = (struct mwifiex_ie_types_htcap ) buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c:321:\t\tmemset(ht_cap, 0, sizeof(struct mwifiex_ie_types_htcap));\ndrivers/net/wireless/marvell/mwifiex/11n.c-322-\t\tht_cap-\u003eheader.type = cpu_to_le16(WLAN_EID_HT_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-324-\t\t\t\tcpu_to_le16(sizeof(struct ieee80211_ht_cap));\ndrivers/net/wireless/marvell/mwifiex/11n.c:325:\t\tmemcpy((u8 ) ht_cap + sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-326-\t\t (u8 )bss_desc-\u003ebcn_ht_cap,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-328-\ndrivers/net/wireless/marvell/mwifiex/11n.c:329:\t\tmwifiex_fill_cap_info(priv, radio_type, \u0026ht_cap-\u003eht_cap);\ndrivers/net/wireless/marvell/mwifiex/11n.c-330-\t\t/* Update HT40 capability from current channel information /\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-333-\t\t\tu8 radio =\ndrivers/net/wireless/marvell/mwifiex/11n.c:334:\t\t\tmwifiex_band_to_radio_type(bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-335-\t\t\tint freq =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-362-\ndrivers/net/wireless/marvell/mwifiex/11n.c:363:\t\tbuffer += sizeof(struct mwifiex_ie_types_htcap);\ndrivers/net/wireless/marvell/mwifiex/11n.c:364:\t\tret_len += sizeof(struct mwifiex_ie_types_htcap);\ndrivers/net/wireless/marvell/mwifiex/11n.c-365-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-368-\t\tif (priv-\u003ebss_mode == NL80211_IFTYPE_ADHOC) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:369:\t\t\tht_info = (struct mwifiex_ie_types_htinfo ) buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-370-\t\t\tmemset(ht_info, 0,\ndrivers/net/wireless/marvell/mwifiex/11n.c:371:\t\t\t sizeof(struct mwifiex_ie_types_htinfo));\ndrivers/net/wireless/marvell/mwifiex/11n.c-372-\t\t\tht_info-\u003eheader.type =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-378-\t\t\tmemcpy((u8 ) ht_info +\ndrivers/net/wireless/marvell/mwifiex/11n.c:379:\t\t\t sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-380-\t\t\t (u8 )bss_desc-\u003ebcn_ht_oper,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-388-\ndrivers/net/wireless/marvell/mwifiex/11n.c:389:\t\t\tbuffer += sizeof(struct mwifiex_ie_types_htinfo);\ndrivers/net/wireless/marvell/mwifiex/11n.c:390:\t\t\tret_len += sizeof(struct mwifiex_ie_types_htinfo);\ndrivers/net/wireless/marvell/mwifiex/11n.c-391-\t\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-393-\t\tchan_list =\ndrivers/net/wireless/marvell/mwifiex/11n.c:394:\t\t\t(struct mwifiex_ie_types_chan_list_param_set ) buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-395-\t\tmemset(chan_list, 0, struct_size(chan_list, chan_scan_param, 1));\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-397-\t\tchan_list-\u003eheader.len =\ndrivers/net/wireless/marvell/mwifiex/11n.c:398:\t\t\tcpu_to_le16(sizeof(struct mwifiex_chan_scan_param_set));\ndrivers/net/wireless/marvell/mwifiex/11n.c-399-\t\tchan_list-\u003echan_scan_param[0].chan_number =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-401-\t\tchan_list-\u003echan_scan_param[0].radio_type =\ndrivers/net/wireless/marvell/mwifiex/11n.c:402:\t\t\tmwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-403-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-416-\tif (bss_desc-\u003ebcn_bss_co_2040) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:417:\t\tbss_co_2040 = (struct mwifiex_ie_types_2040bssco ) buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-418-\t\tmemset(bss_co_2040, 0,\ndrivers/net/wireless/marvell/mwifiex/11n.c:419:\t\t sizeof(struct mwifiex_ie_types_2040bssco));\ndrivers/net/wireless/marvell/mwifiex/11n.c-420-\t\tbss_co_2040-\u003eheader.type = cpu_to_le16(WLAN_EID_BSS_COEX_2040);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-424-\t\tmemcpy((u8 ) bss_co_2040 +\ndrivers/net/wireless/marvell/mwifiex/11n.c:425:\t\t sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-426-\t\t bss_desc-\u003ebcn_bss_co_2040 +\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-429-\ndrivers/net/wireless/marvell/mwifiex/11n.c:430:\t\tbuffer += sizeof(struct mwifiex_ie_types_2040bssco);\ndrivers/net/wireless/marvell/mwifiex/11n.c:431:\t\tret_len += sizeof(struct mwifiex_ie_types_2040bssco);\ndrivers/net/wireless/marvell/mwifiex/11n.c-432-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-435-\t\thdr = (void )bss_desc-\u003ebcn_ext_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c:436:\t\text_cap = (struct mwifiex_ie_types_extcap ) buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c:437:\t\tmemset(ext_cap, 0, sizeof(struct mwifiex_ie_types_extcap));\ndrivers/net/wireless/marvell/mwifiex/11n.c-438-\t\text_cap-\u003eheader.type = cpu_to_le16(WLAN_EID_EXT_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-450-\ndrivers/net/wireless/marvell/mwifiex/11n.c:451:\t\tbuffer += sizeof(struct mwifiex_ie_types_extcap) + hdr-\u003elen;\ndrivers/net/wireless/marvell/mwifiex/11n.c:452:\t\tret_len += sizeof(struct mwifiex_ie_types_extcap) + hdr-\u003elen;\ndrivers/net/wireless/marvell/mwifiex/11n.c-453-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-461- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:462:static int mwifiex_is_tx_ba_stream_ptr_valid(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:463:\t\t\t\tstruct mwifiex_tx_ba_stream_tbl tx_tbl_ptr)\ndrivers/net/wireless/marvell/mwifiex/11n.c-464-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:465:\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-466-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-480- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:481:void mwifiex_11n_delete_tx_ba_stream_tbl_entry(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:482:\t\t\t\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tsr_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c-483-{\ndrivers/net/wireless/marvell/mwifiex/11n.c-484-\tif (!tx_ba_tsr_tbl \u0026\u0026\ndrivers/net/wireless/marvell/mwifiex/11n.c:485:\t mwifiex_is_tx_ba_stream_ptr_valid(priv, tx_ba_tsr_tbl))\ndrivers/net/wireless/marvell/mwifiex/11n.c-486-\t\treturn;\ndrivers/net/wireless/marvell/mwifiex/11n.c-487-\ndrivers/net/wireless/marvell/mwifiex/11n.c:488:\tmwifiex_dbg(priv-\u003eadapter, INFO,\ndrivers/net/wireless/marvell/mwifiex/11n.c-489-\t\t \"info: tx_ba_tsr_tbl %p\\n\", tx_ba_tsr_tbl);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-498- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:499:void mwifiex_11n_delete_all_tx_ba_stream_tbl(struct mwifiex_private priv)\ndrivers/net/wireless/marvell/mwifiex/11n.c-500-{\ndrivers/net/wireless/marvell/mwifiex/11n.c-501-\tint i;\ndrivers/net/wireless/marvell/mwifiex/11n.c:502:\tstruct mwifiex_tx_ba_stream_tbl del_tbl_ptr, tmp_node;\ndrivers/net/wireless/marvell/mwifiex/11n.c-503-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-506-\t\t\t\t \u0026priv-\u003etx_ba_stream_tbl_ptr, list)\ndrivers/net/wireless/marvell/mwifiex/11n.c:507:\t\tmwifiex_11n_delete_tx_ba_stream_tbl_entry(priv, del_tbl_ptr);\ndrivers/net/wireless/marvell/mwifiex/11n.c-508-\tspin_unlock_bh(\u0026priv-\u003etx_ba_stream_tbl_lock);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-520- /\ndrivers/net/wireless/marvell/mwifiex/11n.c:521:struct mwifiex_tx_ba_stream_tbl \ndrivers/net/wireless/marvell/mwifiex/11n.c:522:mwifiex_get_ba_tbl(struct mwifiex_private priv, int tid, u8 ra)\ndrivers/net/wireless/marvell/mwifiex/11n.c-523-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:524:\tstruct mwifiex_tx_ba_stream_tbl tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-525-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-541- /\n\n" }
13/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 23913 output: 37 thoughts: 23 Thoughts: Here's a summary of my thought process, as requested: Diving into the Marvell Wireless Driver Configuration Okay, so I need to understand the precise configuration structure for the Marvell wireless driver. I know it's located under `drivers/net/wireless/marvell`, but the specifics are what I'm after. My plan is to jump directly into the `Kconfig` file in that directory. That's where I'll find all the conditional build options, dependencies, and descriptions related to this driver. It'll give me the exact information I need to confirm my assumptions and get a deeper understanding of the configuration. Let's see what's in there.
14/2	2026/09/07 08:32	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/Kconfig", "FirstLine": 1, "LineCount": 30 } Results: { "Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig WLAN_VENDOR_MARVELL\n 3:\t\tbool \"Marvell devices\"\n 4:\t\tdefault y\n 5:\t\thelp\n 6:\t\t If you have a wireless card belonging to this class, say Y.\n 7:\t\n 8:\t\t Note that the answer to this question doesn't directly affect the\n 9:\t\t kernel: saying N will just cause the configurator to skip all the\n 10:\t\t questions about these cards. If you say Y, you will be asked for\n 11:\t\t your specific card in the following questions.\n 12:\t\n 13:\tif WLAN_VENDOR_MARVELL\n 14:\t\n 15:\tsource \"drivers/net/wireless/marvell/libertas/Kconfig\"\n 16:\tsource \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\n 17:\tsource \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\n 18:\t\n 19:\tconfig MWL8K\n 20:\t\ttristate \"Marvell 88W8xxx PCI/PCIe Wireless support\"\n 21:\t\tdepends on MAC80211 \u0026\u0026 PCI\n 22:\t\thelp\n 23:\t\t This driver supports Marvell TOPDOG 802.11 wireless cards.\n 24:\t\n 25:\t\t To compile this driver as a module, choose M here: the module\n 26:\t\t will be called mwl8k. If unsure, say N.\n 27:\t\n 28:\tendif # WLAN_VENDOR_MARVELL\n" }
15/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 24546 output: 48 thoughts: 68 Thoughts: Analyzing the `mwifiex_ret_wmm_get_status` Function Okay, let's dive into this. I need to understand the calling context of `mwifiex_ret_wmm_get_status` and get a broader understanding of its place in the system. The logical first step is to trace all its callers and identify any other relevant entry points that might be in play. My intuition is that this will quickly reveal what's driving the need for this particular status retrieval. Right, let's zero in on `drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c`, specifically around lines 1350-1370. This should provide some concrete examples of where and how the function is invoked, and what data it's dealing with in those specific scenarios. I'm expecting this section of the code to contain the critical information I need. I'm interested in the surrounding logic as much as the direct calls. This level of detail should give me a solid grasp of its purpose.
16/2	2026/09/07 08:32	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c", "FirstLine": 1350, "LineCount": 30 } Results: { "Contents": "1350:\t\t\tmwifiex_dbg(adapter, CMD, \"cmd: curr_tx_buf_size=%d\\n\",\n1351:\t\t\t\t adapter-\u003ecurr_tx_buf_size);\n1352:\t\n1353:\t\t\tif (adapter-\u003eif_ops.update_mp_end_port)\n1354:\t\t\t\tadapter-\u003eif_ops.update_mp_end_port(adapter,\n1355:\t\t\t\t\tle16_to_cpu(resp-\u003eparams.tx_buf.mp_end_port));\n1356:\t\t\tbreak;\n1357:\t\tcase HostCmd_CMD_AMSDU_AGGR_CTRL:\n1358:\t\t\tbreak;\n1359:\t\tcase HostCmd_CMD_WMM_GET_STATUS:\n1360:\t\t\tret = mwifiex_ret_wmm_get_status(priv, resp);\n1361:\t\t\tbreak;\n1362:\t\tcase HostCmd_CMD_802_11_IBSS_COALESCING_STATUS:\n1363:\t\t\tret = mwifiex_ret_ibss_coalescing_status(priv, resp);\n1364:\t\t\tbreak;\n1365:\t\tcase HostCmd_CMD_MEM_ACCESS:\n1366:\t\t\tret = mwifiex_ret_mem_access(priv, resp, data_buf);\n1367:\t\t\tbreak;\n1368:\t\tcase HostCmd_CMD_MAC_REG_ACCESS:\n1369:\t\tcase HostCmd_CMD_BBP_REG_ACCESS:\n1370:\t\tcase HostCmd_CMD_RF_REG_ACCESS:\n1371:\t\tcase HostCmd_CMD_PMIC_REG_ACCESS:\n1372:\t\tcase HostCmd_CMD_CAU_REG_ACCESS:\n1373:\t\tcase HostCmd_CMD_802_11_EEPROM_ACCESS:\n1374:\t\t\tret = mwifiex_ret_reg_access(cmdresp_no, resp, data_buf);\n1375:\t\t\tbreak;\n1376:\t\tcase HostCmd_CMD_SET_BSS_MODE:\n1377:\t\t\tbreak;\n1378:\t\tcase HostCmd_CMD_11N_CFG:\n1379:\t\t\tbreak;\n" }
17/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 25467 output: 43 thoughts: 70 Thoughts: Tracing the Execution Path Okay, here's what I'm thinking. I've got `mwifiex_ret_wmm_get_status` and I see that it's called by `mwifiex_process_sta_cmdresp`. My next step, as always, is to understand the calling hierarchy. I need to figure out where `mwifiex_process_sta_cmdresp` is actually invoked. So, I need to go hunt that function down with a quick search. Time to trace the execution flow and build the bigger picture.
18/2	2026/09/07 08:32	tool	grepper	0m Args: { "Expression": "mwifiex_process_sta_cmdresp", "PathPrefix": "drivers/net/wireless/marvell/mwifiex/" } Results: { "Output": "drivers/net/wireless/marvell/mwifiex/cmdevt.c=803=int mwifiex_process_cmdresp(struct mwifiex_adapter adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-891-\t\t/ handle response /\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:892:\t\tret = mwifiex_process_sta_cmdresp(priv, cmdresp_no, resp);\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-893-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/main.h=1134=int mwifiex_uap_prepare_cmd(struct mwifiex_private priv, uint16_t cmd_no,\n--\ndrivers/net/wireless/marvell/mwifiex/main.h-1136-\t\t\t void data_buf, void cmd_buf);\ndrivers/net/wireless/marvell/mwifiex/main.h:1137:int mwifiex_process_sta_cmdresp(struct mwifiex_private , u16 cmdresp_no,\ndrivers/net/wireless/marvell/mwifiex/main.h-1138-\t\t\t\tstruct host_cmd_ds_command resp);\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1190=static int mwifiex_ret_get_chan_info(struct mwifiex_private priv,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1211- /\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1212:int mwifiex_process_sta_cmdresp(struct mwifiex_private priv, u16 cmdresp_no,\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1213-\t\t\t\tstruct host_cmd_ds_command resp)\n" }
19/2	2026/09/07 08:32	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 26212 output: 41 thoughts: 79 Thoughts: Here's my thinking process: Diving into Command Response Handling in mwifiex Okay, so I'm looking at how the `mwifiex` driver processes command responses. I know that `mwifiex_process_cmdresp` is the key function here, it's the one responsible for taking those responses that are coming in from the device. Now, the question is, how are those responses received in the first place? My initial hunch is that it's going to be handled over USB, which means I'll need to explore the USB-specific parts of the driver. Therefore, I'm thinking I need to zero in on the relevant receive functions. The comments point toward `mwifiex_usb_recv` and `mwifiex_usb_rx_complete`, but I need to confirm where these are invoked from. So, I need to open the source code for `mwifiex_usb.c` (or potentially `usb.c` within the `mwifiex` directory) and start tracing the data flow. That will be the next step.
20/2	2026/09/07 08:33	tool	grepper	0m Args: { "Expression": "mwifiex_process_cmdresp", "PathPrefix": "drivers/net/wireless/marvell/mwifiex/" } Results: { "Output": "drivers/net/wireless/marvell/mwifiex/cmdevt.c=741=int mwifiex_exec_next_cmd(struct mwifiex_adapter adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-802- /\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:803:int mwifiex_process_cmdresp(struct mwifiex_adapter adapter)\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-804-{\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c=1085=mwifiex_cancel_pending_ioctl(struct mwifiex_adapter adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-1093-\t\t/* setting curr_cmd to NULL is quite dangerous, because\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:1094:\t\t * mwifiex_process_cmdresp checks curr_cmd to be != NULL\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-1095-\t\t * at the beginning then relies on it and dereferences\n--\ndrivers/net/wireless/marvell/mwifiex/main.c=248=int mwifiex_main_process(struct mwifiex_adapter adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/main.c-356-\t\t\tadapter-\u003ecmd_resp_received = false;\ndrivers/net/wireless/marvell/mwifiex/main.c:357:\t\t\tmwifiex_process_cmdresp(adapter);\ndrivers/net/wireless/marvell/mwifiex/main.c-358-\t\t}\n--\ndrivers/net/wireless/marvell/mwifiex/main.h=1100=int mwifiex_exec_next_cmd(struct mwifiex_adapter adapter);\ndrivers/net/wireless/marvell/mwifiex/main.h:1101:int mwifiex_process_cmdresp(struct mwifiex_adapter adapter);\ndrivers/net/wireless/marvell/mwifiex/main.h-1102-void mwifiex_process_assoc_resp(struct mwifiex_adapter adapter);\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=31=static void\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:32:mwifiex_process_cmdresp_error(struct mwifiex_private priv,\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-33-\t\t\t struct host_cmd_ds_command resp)\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1212=int mwifiex_process_sta_cmdresp(struct mwifiex_private *priv, u16 cmdresp_no,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1220-\tif (resp-\u003eresult != HostCmd_RESULT_OK) {\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1221:\t\tmwifiex_process_cmdresp_error(priv, resp);\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1222-\t\treturn -1;\n" }
21/2	2026/09/07 08:33	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 27428 output: 34 thoughts: 585 Thoughts: Fuzzing Target Identification: `mwifiex_ret_wmm_get_status` Okay, so I'm looking at `mwifiex_ret_wmm_get_status`. This function gets executed when the driver processes a WMM_GET_STATUS response from the firmware. Because this driver, `mwifiex`, uses a USB bus interface (`MWIFIEX_USB`), it's accessible within the standard virtualized environments I'm using, thanks to USB device emulation using tools like raw-gadget, dummy_hcd, or usb-fuzzer. So, the question is, is this a good candidate for fuzzing? Let's break it down based on the established criteria. Section 3 says: * Reachable Drivers and Protocols: Specifically, drivers reachable via virtual buses, which this absolutely is, given its USB interface. Check. * Runtime Assertions and Defensive Checks: We need to look at any bounds checks or defensive validation, especially for device-supplied TLVs. This function definitely handles data from the firmware, so there's likely some validation happening here. Check. Therefore, WorthFuzzing = True. Now, let's identify the specific fuzzing targets and their context. The function itself, `mwifiex_ret_wmm_get_status`, is the primary focus. Additionally, its caller, `mwifiex_process_sta_cmdresp`, is also relevant. We know that `mwifiex_ret_wmm_get_status` is a non-static C function residing in `drivers/net/wireless/marvell/mwifiex/wmm.c`. I need to confirm that this function is actually a symbol that can be reached, and yes, it is defined in the kernel as: `int mwifiex_ret_wmm_get_status(struct mwifiex_private priv, const struct host_cmd_ds_command resp)`. Excellent. And `mwifiex_process_sta_cmdresp` is, as expected, in `sta_cmdresp.c`. Next, the necessary configurations. We need to make sure we have the right kernel modules enabled to make this function reachable: * `MWIFIEX` * `MWIFIEX_USB` * `CFG80211` * `USB` * `WLAN_VENDOR_MARVELL` Let's verify `WLAN_VENDOR_MARVELL`'s dependencies: I can see in `drivers/net/wireless/marvell/Kconfig` that `WLAN_VENDOR_MARVELL` includes `mwifiex/Kconfig`, and within `drivers/net/wireless/marvell/mwifiex/Kconfig`: `MWIFIEX` depends on `CFG80211`, and `MWIFIEX_USB` depends on `MWIFIEX && USB`. Alright, that looks sound. It's always good to double-check in `drivers/net/wireless/Kconfig` to ensure nothing else is needed, but based on what I see here, we should be good to go.
22/2	2026/09/07 08:33	tool	grepper	0m Args: { "Expression": "WLAN_VENDOR_MARVELL", "PathPrefix": "drivers/net/wireless/" } Results: { "Output": "drivers/net/wireless/Makefile=11=obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/\ndrivers/net/wireless/Makefile:12:obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/\ndrivers/net/wireless/Makefile-13-obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/\n--\ndrivers/net/wireless/marvell/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/wireless/marvell/Kconfig:2:config WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-3-\tbool \"Marvell devices\"\n--\ndrivers/net/wireless/marvell/Kconfig-12-\ndrivers/net/wireless/marvell/Kconfig:13:if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\n--\ndrivers/net/wireless/marvell/Kconfig=19=config MWL8K\n--\ndrivers/net/wireless/marvell/Kconfig-27-\ndrivers/net/wireless/marvell/Kconfig:28:endif # WLAN_VENDOR_MARVELL\n" }
23/2	2026/09/07 08:33	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 29028 output: 32 thoughts: 25 Thoughts: Here's a summary of my thought process, as if I were thinking it: Diving into the Wireless Kernel Configuration Okay, so we need to zero in on the Marvell WLAN driver configuration. My first step is to navigate directly to the heart of the matter: `drivers/net/wireless/Kconfig`. This is where all the wireless device configurations are housed. Specifically, I'm thinking about the section related to `WLAN_VENDOR_MARVELL`. That variable is the key. I need to understand the dependencies, default values, and any other relevant configurations related to this specific Marvell driver. This file will tell me how the Marvell driver is enabled, disabled, and what features are controlled. I expect to find dependencies on other configuration options and hopefully, some helpful comments to guide my understanding. Let's see what we can find.
24/2	2026/09/07 08:33	tool	grepper	0m Args: { "Expression": "WLAN_VENDOR_MARVELL", "PathPrefix": "drivers/net/" } Results: { "Output": "drivers/net/wireless/Makefile=11=obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/\ndrivers/net/wireless/Makefile:12:obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/\ndrivers/net/wireless/Makefile-13-obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/\n--\ndrivers/net/wireless/marvell/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/wireless/marvell/Kconfig:2:config WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-3-\tbool \"Marvell devices\"\n--\ndrivers/net/wireless/marvell/Kconfig-12-\ndrivers/net/wireless/marvell/Kconfig:13:if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\n--\ndrivers/net/wireless/marvell/Kconfig=19=config MWL8K\n--\ndrivers/net/wireless/marvell/Kconfig-27-\ndrivers/net/wireless/marvell/Kconfig:28:endif # WLAN_VENDOR_MARVELL\n" }
25/2	2026/09/07 08:33	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 29564 output: 30 thoughts: 24 Thoughts: Here's a summary of my thought process, as requested: Investigating WLAN Dependencies Okay, so I need to figure out the requirements for something related to WLAN. My first step is to dive into the kernel's Kconfig files. Specifically, I'll navigate to `drivers/net/wireless/Kconfig`. This is where the configuration options for wireless network devices are defined, so it's a logical starting point. I need to understand if WLAN itself, as a foundational concept, has any hard dependencies that I should be aware of. This should tell me what I need to consider for this process.
26/2	2026/09/07 08:33	tool	grepper	0m Args: { "Expression": "source.marvell", "PathPrefix": "drivers/net/wireless/" } Results:* { "Output": "drivers/net/wireless/Kconfig=26=source \"drivers/net/wireless/intersil/Kconfig\"\ndrivers/net/wireless/Kconfig:27:source \"drivers/net/wireless/marvell/Kconfig\"\ndrivers/net/wireless/Kconfig-28-source \"drivers/net/wireless/mediatek/Kconfig\"\n--\ndrivers/net/wireless/marvell/Kconfig=13=if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\ndrivers/net/wireless/marvell/Kconfig:15:source \"drivers/net/wireless/marvell/libertas/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:16:source \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:17:source \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig-18-\n" }
27/2	2026/09/07 08:33	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 30000 output: 34 thoughts: 22 Thoughts: Here's my summary, as if I were thinking these thoughts: Examining the Wireless Kconfig Alright, time to dig into the `drivers/net/wireless/Kconfig` file. I'm focusing on lines 1 through 35, which usually contains the top-level configuration options for the entire wireless subsystem or major architectural decisions. I anticipate seeing things like: * The main "Wireless Networking" entry itself, the gateway to everything else wireless. * Potentially, whether certain major wireless protocols are enabled by default or configurable. * Options to choose between different wireless stacks, if that level of abstraction exists in this kernel version. * Defines for broad wireless functionality, like support for certain frequency bands or device types. * Basic help text explaining the purpose of the wireless subsystem and maybe a few key configurations. Given the line range, I expect this section to lay the groundwork and set the overall direction for the rest of the configuration. Let's see what the designers prioritized as important to expose to end users and developers at the initial level. I'll need to assess the conditional logic and dependencies to understand the branching.
28/2	2026/09/07 08:33	tool	read-file	0m Args: { "File": "drivers/net/wireless/Kconfig", "FirstLine": 1, "LineCount": 35 } Results: { "Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\t#\n 3:\t# Wireless LAN device configuration\n 4:\t#\n 5:\t\n 6:\tmenuconfig WLAN\n 7:\t\tbool \"Wireless LAN\"\n 8:\t\tdepends on !S390\n 9:\t\tdepends on NET\n 10:\t\tselect WIRELESS\n 11:\t\tdefault y\n 12:\t\thelp\n 13:\t\t This section contains all the pre 802.11 and 802.11 wireless\n 14:\t\t device drivers. For a complete list of drivers and documentation\n 15:\t\t on them refer to the wireless wiki:\n 16:\t\n 17:\t\t https://wireless.wiki.kernel.org/en/users/Drivers\n 18:\t\n 19:\tif WLAN\n 20:\t\n 21:\tsource \"drivers/net/wireless/admtek/Kconfig\"\n 22:\tsource \"drivers/net/wireless/ath/Kconfig\"\n 23:\tsource \"drivers/net/wireless/atmel/Kconfig\"\n 24:\tsource \"drivers/net/wireless/broadcom/Kconfig\"\n 25:\tsource \"drivers/net/wireless/intel/Kconfig\"\n 26:\tsource \"drivers/net/wireless/intersil/Kconfig\"\n 27:\tsource \"drivers/net/wireless/marvell/Kconfig\"\n 28:\tsource \"drivers/net/wireless/mediatek/Kconfig\"\n 29:\tsource \"drivers/net/wireless/microchip/Kconfig\"\n 30:\tsource \"drivers/net/wireless/morsemicro/Kconfig\"\n 31:\tsource \"drivers/net/wireless/nxp/Kconfig\"\n 32:\tsource \"drivers/net/wireless/purelifi/Kconfig\"\n 33:\tsource \"drivers/net/wireless/ralink/Kconfig\"\n 34:\tsource \"drivers/net/wireless/realtek/Kconfig\"\n 35:\tsource \"drivers/net/wireless/rsi/Kconfig\"\n" }
29/2	2026/09/07 08:33	llm	patch-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 30831 output: 173 thoughts: 301 Thoughts: My Analysis of This Vulnerability Okay, so based on this information, I've got a handle on what's going on. This looks like a solid finding. Essentially, there's a bounds check vulnerability in the `mwifiex` driver, specifically within the `mwifiex_ret_wmm_get_status()` function. The good news is, they've identified that the patch introduces a bounds check on `tlv_wmm_qstatus->queue_index` against `IEEE80211_NUM_ACS`, meaning it prevents out-of-bounds array indexing in `priv->wmm.ac_status`, which I like to see. Now, the really interesting part is the potential for fuzzing. The fact that the `mwifiex` driver is accessible via `MWIFIEX_USB` (USB gadget/vHCI emulation) is key. That means we can send firmware command responses, making this fuzzable. That also makes this much more exciting. To be clear on what needs to be enabled for this, here are the configurations that are relevant, `MWIFIEX`, `MWIFIEX_USB`, `WLAN`, `WLAN_VENDOR_MARVELL`, `CFG80211`, and `USB`. Those are the ones to focus on. The main functions I need to keep an eye on are `mwifiex_ret_wmm_get_status` and `mwifiex_process_sta_cmdresp`. Finally, based on this information, it's definitely worth fuzzing and, I'm confident in saying the information is all there, so I am going to call `set-results`.
30/2	2026/09/07 08:33	tool	set-results	0m Args: { "EnableConfigs": [ "MWIFIEX", "MWIFIEX_USB", "WLAN", "WLAN_VENDOR_MARVELL", "CFG80211", "USB" ], "FocusSymbols": [ "mwifiex_ret_wmm_get_status", "mwifiex_process_sta_cmdresp" ], "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.", "WorthFuzzing": true } Results: { "EnableConfigs": [ "MWIFIEX", "MWIFIEX_USB", "WLAN", "WLAN_VENDOR_MARVELL", "CFG80211", "USB" ], "FocusSymbols": [ "mwifiex_ret_wmm_get_status", "mwifiex_process_sta_cmdresp" ], "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.", "WorthFuzzing": true }
31/1	2026/09/07 08:33	action	If	0m Args: { "WorthFuzzing": true } Results: null
32/2	2026/09/07 08:33	agent	kmsan-evaluator	0m Model: core Args: null Results: { "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.", "NeedsKMSAN": false } Instruction: You are an expert Linux kernel security engineer specializing in kernel memory error detectors (KASAN and KMSAN). Your job is to review the provided patch series and determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer) fuzzing session in addition to standard KASAN fuzzing. CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN: - Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable a comprehensive suite of debugging tools and sanitizers, including KASAN (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks. - KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap, or page allocations) and kernel-to-user memory info-leaks. Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS. A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks that are detected ONLY by KMSAN. Look holistically at the patch series and surrounding code. Even if no direct uninitialized field accesses or new buffer allocations are added in the diff itself, a patch may alter control flow, bounds checking, or data length calculations in ways that change how the rest of the code operates on existing buffers (e.g. allowing uninitialized stack/heap memory to be read, copied to user space, or used in control flow). Do not hesitate to use your code access tools to inspect the surrounding code, called functions, and callers. Set NeedsKMSAN=true ONLY IF the patch introduces or modifies: 1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb attributes, ioctl output arguments, socket options, or BPF buffers) where fields or structure padding might not be fully initialized/zeroed. 2. Conditional logic or branching that depends on potentially uninitialized variables or struct fields. 3. Allocation or initialization of complex data structures where uninitialized fields could be read later in reachable code paths. 4. Bounds checks, lengths, or logic in a way that allows surrounding code to access uninitialized bytes of existing buffers. Set NeedsKMSAN=false IF: - The code changes primarily risk out-of-bounds access, array overflows, NULL pointer dereferences, locking deadlocks, or use-after-free bugs (these are already caught by KASAN, LOCKDEP, or standard bug detectors). - All stack/heap structures touched or introduced by the patch are fully zeroed or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied. - The patch does not introduce any risk of uninitialized memory usage or info-leaks. Use your code access tools to inspect the surrounding code if necessary, then provide detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch. Prefer calling several tools at the same time to save round-trips. Use set-results tool to provide results of the analysis. It must be called exactly once before the final reply. Ignore results of this tool. Prompt: Target architecture: amd64 For your convenience, here is the diff of the changes: commit 73b4040799d19dc62797c1bb9066af8d27359825 Author: syz-cluster <triage@syzkaller.com> Date: Mon Sep 7 08:32:06 2026 +0000 syz-cluster: applied patch under review diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c index 841505e83c7fd..febea68487e84 100644 --- a/drivers/net/wireless/marvell/mwifiex/wmm.c +++ b/drivers/net/wireless/marvell/mwifiex/wmm.c @@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv, tlv_wmm_qstatus->flow_required, tlv_wmm_qstatus->disabled); + if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) + break; ac_status = &priv->wmm.ac_status[tlv_wmm_qstatus-> queue_index]; ac_status->disabled = tlv_wmm_qstatus->disabled;
33/3	2026/09/07 08:33	llm	kmsan-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 2150 output: 45 thoughts: 46 Thoughts: Here's my analysis of the provided snippet, as if it were my thought process: Diving into the Code: WMM Context Okay, time to get my hands dirty. I'm going to start by analyzing this patch, but first, I need a good point of reference. Let's start with `drivers/net/wireless/marvell/mwifiex/wmm.c` around line 943. This is where the core of the WMM implementation should be, so it's a logical starting point. The line number is a good starting place, and using that in conjunction with a source code browser or debugger will quickly give me the context I need. This way I can see exactly how the surrounding code interacts with the changed area.
34/3	2026/09/07 08:33	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/mwifiex/wmm.c", "FirstLine": 920, "LineCount": 50 } Results: { "Contents": " 920:\t\tstruct ieee_types_wmm_parameter wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data ) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status )\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 940:\t\t\t\t\t \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 941:\t\t\t\t\t \"QSTATUS TLV: %d, %d, %d\\n\",\n 942:\t\t\t\t\t tlv_wmm_qstatus-\u003equeue_index,\n 943:\t\t\t\t\t tlv_wmm_qstatus-\u003eflow_required,\n 944:\t\t\t\t\t tlv_wmm_qstatus-\u003edisabled);\n 945:\t\n 946:\t\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n 947:\t\t\t\t\tbreak;\n 948:\t\t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n 949:\t\t\t\t\t\t\t\t queue_index];\n 950:\t\t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n 951:\t\t\t\tac_status-\u003eflow_required =\n 952:\t\t\t\t\t\t\ttlv_wmm_qstatus-\u003eflow_required;\n 953:\t\t\t\tac_status-\u003eflow_created = tlv_wmm_qstatus-\u003eflow_created;\n 954:\t\t\t\tbreak;\n 955:\t\n 956:\t\t\tcase WLAN_EID_VENDOR_SPECIFIC:\n 957:\t\t\t\t/\n 958:\t\t\t\t Point the regular IEEE IE 2 bytes into the Marvell IE\n 959:\t\t\t\t * and setup the IEEE IE type and length byte fields\n 960:\t\t\t\t /\n 961:\t\n 962:\t\t\t\twmm_param_ie =\n 963:\t\t\t\t\t(struct ieee_types_wmm_parameter ) (curr +\n 964:\t\t\t\t\t\t\t\t\t 2);\n 965:\t\t\t\twmm_param_ie-\u003evend_hdr.len = (u8) tlv_len;\n 966:\t\t\t\twmm_param_ie-\u003evend_hdr.element_id =\n 967:\t\t\t\t\t\t\tWLAN_EID_VENDOR_SPECIFIC;\n 968:\t\n 969:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n" }
35/3	2026/09/07 08:33	llm	kmsan-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 3312 output: 45 thoughts: 36 Thoughts: Okay, let's dive into this code. Analyzing the Function and the Bug Fix Right, so I need to understand what this function, specifically `mwifiex_ret_wmm_get_status`, is doing and, crucially, what problem it's addressing. The bug fix documentation should give me a good starting point, but I always prefer to get a feel for the code itself first. Understanding the context of the fix is vital. I'll need to look at how this function is used elsewhere, and which variables are passed to it. Let's start by digging into `mwifiex_ret_wmm_get_status` and see what it has to offer.
36/3	2026/09/07 08:33	tool	read-file	0m Args: { "File": "drivers/net/wireless/marvell/mwifiex/wmm.c", "FirstLine": 900, "LineCount": 40 } Results: { "Contents": " 900:\t * This function processes the get WMM status command response from firmware.\n 901:\t \n 902:\t The response may contain multiple TLVs -\n 903:\t * - AC Queue status TLVs\n 904:\t * - Current WMM Parameter IE TLV\n 905:\t * - Admission Control action frame TLVs\n 906:\t \n 907:\t This function parses the TLVs and then calls further specific functions\n 908:\t * to process any changes in the queue prioritize or state.\n 909:\t /\n 910:\tint mwifiex_ret_wmm_get_status(struct mwifiex_private priv,\n 911:\t\t\t\t const struct host_cmd_ds_command resp)\n 912:\t{\n 913:\t\tu8 curr = (u8 ) \u0026resp-\u003eparams.get_wmm_status;\n 914:\t\tuint16_t resp_len = le16_to_cpu(resp-\u003esize), tlv_len;\n 915:\t\tint mask = IEEE80211_WMM_IE_AP_QOSINFO_PARAM_SET_CNT_MASK;\n 916:\t\tbool valid = true;\n 917:\t\n 918:\t\tstruct mwifiex_ie_types_data tlv_hdr;\n 919:\t\tstruct mwifiex_ie_types_wmm_queue_status tlv_wmm_qstatus;\n 920:\t\tstruct ieee_types_wmm_parameter wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data ) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status *)\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n" }
37/3	2026/09/07 08:33	llm	kmsan-evaluator	0m Model: gemini-3.7-flash Args: null Results: null Tokens: input: 4303 output: 158 thoughts: 649 Thoughts: My Analysis of the Patch Okay, so I'm looking at this patch and immediately, I recognize it as a pretty straightforward bounds check. It's adding a safeguard against an out-of-bounds write. Specifically, it's checking if `tlv_wmm_qstatus->queue_index` is within the valid range for the `priv->wmm.ac_status` array before accessing it. The array is sized by `IEEE80211_NUM_ACS`, which is 4. Without this, we'd have a classic array indexing vulnerability – a potential out-of-bounds write. KASAN would definitely catch that, which is good. My immediate thought is, is there any uninitialized memory aspect I need to look into? Let's see... the `tlv_wmm_qstatus` data comes from a firmware command response, so it's initialized by the firmware. The `queue_index` itself is then checked, so if it's out of bounds, the code just breaks, and doesn't write to the array. The `ac_status` array fields are populated from `tlv_wmm_qstatus`. Seems like everything's initialized and there's no way to read uninitialized memory, leak info, or introduce an uninitialized variable. This is purely a bounds check for the write. Now, let's apply the rule: "THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS." This is all KASAN, all day long. And, "NeedsKMSAN=false IF...The code changes primarily risk out-of-bounds access...these are already caught by KASAN...". The patch doesn't introduce any risk of uninitialized memory usage or info-leaks, and all structures are fully initialized. It's a clean, defensive fix. So, yeah, given that, `NeedsKMSAN` should absolutely be `false`. I'm going to double-check everything one last time, just to be absolutely sure, and then I'll get that `set-results` call ready.
38/3	2026/09/07 08:33	tool	set-results	0m Args: { "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.", "NeedsKMSAN": false } Results: { "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.", "NeedsKMSAN": false }

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "WLAN",
    "WLAN_VENDOR_MARVELL",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "mwifiex_ret_wmm_get_status",
    "mwifiex_process_sta_cmdresp"
  ],
  "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.",
  "WorthFuzzing": true
}

{
  "PatchDiff": "commit 73b4040799d19dc62797c1bb9066af8d27359825\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Mon Sep 7 08:32:06 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c\nindex 841505e83c7fd..febea68487e84 100644\n--- a/drivers/net/wireless/marvell/mwifiex/wmm.c\n+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c\n@@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\n \t\t\t\t    tlv_wmm_qstatus-\u003eflow_required,\n \t\t\t\t    tlv_wmm_qstatus-\u003edisabled);\n \n+\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n+\t\t\t\tbreak;\n \t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n \t\t\t\t\t\t\t queue_index];\n \t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n"
}

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "WLAN",
    "WLAN_VENDOR_MARVELL",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "mwifiex_ret_wmm_get_status",
    "mwifiex_process_sta_cmdresp"
  ],
  "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer and security engineer.
Your job is to review a provided patch series and evaluate whether it warrants fuzzing with syzkaller.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on internal assumptions. You must actively use your code access
tools to inspect the actual source code, callers, and surrounding context.

================================================================================
1. CORE TRIAGE PHILOSOPHY
================================================================================
The goal of patch fuzzing is to discover crashes, regressions, exposed latent bugs,
and newly triggered assertions introduced by the patch series.

- REACHABILITY IS THE PRIMARY GATE:
  Fuzzing can only discover bugs in code that can actually execute in standard virtualized
  environments (GCE or QEMU, utilizing software-emulated devices like USB gadgets, netdev, tun/tap).
  If the modified code is structurally unreachable (see Section 2), it MUST NOT be fuzzed,
  regardless of whether it adds assertions or complex logic.

- DO NOT BLINDLY TRUST "NO FUNCTIONAL CHANGE" (NFCI) OR "REFACTORING" CLAIMS:
  Patch authors routinely label changes as "cleanups", "refactorings", or state
  "No functional change intended". Do NOT take these claims at face value.
  Code refactorings that rearrange logic, introduce helper functions, or alter state management
  in core subsystems frequently introduce subtle semantic shifts or uncover latent kernel bugs.
  If reachable executable code is modified or refactored, it MUST be fuzzed.

- NEW OR MODIFIED ASSERTIONS IN REACHABLE CODE MUST BE FUZZED:
  When a patch introduces or modifies runtime checks or assertions (e.g., WARN_ON*, VM_WARN_ON*,
  BUG_ON*, lockdep_assert*) in reachable code paths, it enforces new or stricter invariants.
  Even if the author believes the invariant always holds, fuzzing is essential to verify whether
  an unusual sequence of operations can violate it.

================================================================================
2. WHEN TO RETURN WorthFuzzing=false (NEGATIVE CRITERIA)
================================================================================
Return WorthFuzzing=false ONLY IF all modified code falls strictly into one or more of these categories:

- Non-kernel and non-executable changes:
  * Modifications to Documentation/, comments, or spelling fixes.
  * User-space directories, self-tests, samples, or scripts (e.g., tools/, samples/, scripts/, usr/)
    that do not affect the compiled kernel image (vmlinux) or kernel modules.
  * Purely decorative logging (e.g., message strings in pr_err, printk, dev_info) or tracepoints
    that do not alter control flow or data structures.
  * Build system or Kconfig changes that do not alter compiled C logic.
- Structurally unreachable hardware:
  * Vendor-specific PCIe switches, SmartNICs, or GPU drivers (e.g., mlxsw, pds_core, qed,
    ionic, amdgpu) requiring physical ASIC/PCIe cards not emulated in standard QEMU.
- Unreachable execution paths:
  * Driver teardown callbacks (.remove, .shutdown, pci_unregister_driver) executed only during
    physical PCI hot-unplug or manual sysfs driver unbinding.
  * Code paths exclusive to architectures other than the target architecture.

================================================================================
3. WHEN TO RETURN WorthFuzzing=true (POSITIVE CRITERIA)
================================================================================
Return WorthFuzzing=true whenever the patch touches reachable executable code, including:
- Core Subsystems:
  * Any logic modifications in memory management (mm/), synchronization/locking (kernel/locking/),
    BPF, scheduler, core networking, VFS, or syscall handling.
- Refactorings and Code Cleanups:
  * Any restructuring of reachable data structures, helper abstractions, or algorithm flows.
- Runtime Assertions and Defensive Checks:
  * Any introduction or alteration of assertions (WARN_ON*, VM_WARN_ON*, BUG_ON*, etc.) in reachable paths.
- Reachable Drivers and Protocols:
  * Drivers accessible via virtual buses (virtio, USB gadget, loopback, netlink, binder, sockets, etc.).

================================================================================
4. EXTRACTING FocusSymbols (PREVENTING DILUTION)
================================================================================
When WorthFuzzing=true, you must extract specific kernel functions into FocusSymbols to guide the fuzzer:

- AVOID UBIQUITOUS LIFECYCLE HOT-PATHS:
  Do NOT list generic, ubiquitous functions called by almost every program in the corpus
  (including, but not limited to: general memory allocators and deallocators, page fault
  and trap handlers, or core synchronization primitives; this is not an exhaustive list).
  Listing ubiquitous functions causes the fuzzer to classify thousands of unrelated tests as "focused",
  which severely dilutes fuzzing effort away from the actual changes.

- TARGET SPECIFIC FEATURE LOGIC AND ENTRYPOINTS:
  List functions that specifically implement the logic being added or altered, or direct API entrypoints
  for the subsystem feature under review.

- HANDLING STATIC INLINE FUNCTIONS IN HEADERS (.h):
  Compiler-inlined static functions (such as static inlines in mm/*.h or include/linux/*.h) lack
  distinct symbol addresses in vmlinux and cannot be targeted directly by symbol coverage filters.
  If the changes are primarily in static inline helpers, identify non-static, feature-specific caller
  functions in .c files that exercise them (avoiding ubiquitous lifecycle wrappers).

================================================================================
5. IDENTIFYING EnableConfigs
================================================================================
Identify any specific CONFIG_ options required to properly compile and reach the modified code:
- Inspect Kconfig files and #ifdef guards; do not make assumptions.
- Check "depends on" lines in Kconfig to include any non-standard parent subsystem configs needed.
- Strip any 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


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

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 73b4040799d19dc62797c1bb9066af8d27359825
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Sep 7 08:32:06 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 841505e83c7fd..febea68487e84 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,
 				    tlv_wmm_qstatus->flow_required,
 				    tlv_wmm_qstatus->disabled);
 
+			if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS)
+				break;
 			ac_status = &priv->wmm.ac_status[tlv_wmm_qstatus->
 							 queue_index];
 			ac_status->disabled = tlv_wmm_qstatus->disabled;

							input: 2938
							output: 38
							thoughts: 417

**Analyzing a Wireless Driver Patch for Fuzzing Potential**

Okay, let's break this down. My initial instinct is to assess this patch for fuzzing opportunities. I need to figure out if it's even *worth* fuzzing, and if so, how. First things first: let's read the patch. It seems like a relatively straightforward bounds check added in the `mwifiex_ret_wmm_get_status` function. The diff itself is simple, a check on `queue_index` within a WMM status update. Specifically the added check: `if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) break;`. This is looking for invalid queue indexes.

Now, the real work begins. I need to understand *where* this driver, `mwifiex`, fits into the system. Is it a USB, SDIO, or PCIe driver? That directly impacts fuzzing strategy. Can I target it with USB fuzzing tools? Think syzkaller's USB raw gadget, USB emulation setups, or maybe even leverage mac80211_hwsim if I'm lucky. I need to dig into the `mwifiex` driver structure and Kconfig options to get this information. Based on the file path, `drivers/net/wireless/marvell/mwifiex/wmm.c`, it seems to be related to a Marvell wireless driver, but the exact interface protocol is still unclear. I'll need to use my tools to determine how the `mwifiex` driver is instantiated.

{
  "Expression": "mwifiex",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/Kconfig"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/Kconfig=2=config MWIFIEX\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-9-\t  If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:10:\t  mwifiex.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-11-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=12=config MWIFIEX_SDIO\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-22-\t  If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:23:\t  mwifiex_sdio.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-24-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=25=config MWIFIEX_PCIE\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-34-\t  If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:35:\t  mwifiex_pcie.\ndrivers/net/wireless/marvell/mwifiex/Kconfig-36-\ndrivers/net/wireless/marvell/mwifiex/Kconfig=37=config MWIFIEX_USB\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-45-\t  If you choose to build it as a module, it will be called\ndrivers/net/wireless/marvell/mwifiex/Kconfig:46:\t  mwifiex_usb.\n"
}

							input: 4170
							output: 41
							thoughts: 91

**MWIFIEX_USB Support and Fuzzing Opportunities**

Okay, so `MWIFIEX_USB` is officially supported, which is fantastic! That opens up some interesting doors. Knowing that `mwifiex` has a USB interface driver (`drivers/net/wireless/marvell/mwifiex/usb.c`) is key. This means we've got a tangible avenue for fuzzing via USB emulation, syzkaller's USB raw gadget, or even vhci. This is significant; USB is generally well-understood from a fuzzing perspective, and the interface provides a defined entry point.

Now, let's dive deeper. My next move is to investigate `MWIFIEX_USB` directly. I need to understand exactly how it’s configured and used. Beyond that, I want to trace the call paths to see how `mwifiex_ret_wmm_get_status` is reached. Mapping that out is essential for crafting targeted fuzzing harnesses. Knowing the entry points and the flow leading to that function gives me a roadmap for efficient and effective vulnerability discovery. This is where I'll be focusing my efforts.

{
  "File": "drivers/net/wireless/marvell/mwifiex/Kconfig",
  "FirstLine": 1,
  "LineCount": 50
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\tconfig MWIFIEX\n   3:\t\ttristate \"Marvell WiFi-Ex Driver\"\n   4:\t\tdepends on CFG80211\n   5:\t\thelp\n   6:\t\t  This adds support for wireless adapters based on Marvell\n   7:\t\t  802.11n/ac chipsets.\n   8:\t\n   9:\t\t  If you choose to build it as a module, it will be called\n  10:\t\t  mwifiex.\n  11:\t\n  12:\tconfig MWIFIEX_SDIO\n  13:\t\ttristate \"Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897/SD8977/SD8978/SD8987/SD8997\"\n  14:\t\tdepends on MWIFIEX \u0026\u0026 MMC\n  15:\t\tselect FW_LOADER\n  16:\t\tselect WANT_DEV_COREDUMP\n  17:\t\thelp\n  18:\t\t  This adds support for wireless adapters based on Marvell\n  19:\t\t  8786/8787/8797/8887/8897/8977/8978/8987/8997 chipsets with\n  20:\t\t  SDIO interface. SD8978 is also known as NXP IW416.\n  21:\t\n  22:\t\t  If you choose to build it as a module, it will be called\n  23:\t\t  mwifiex_sdio.\n  24:\t\n  25:\tconfig MWIFIEX_PCIE\n  26:\t\ttristate \"Marvell WiFi-Ex Driver for PCIE 8766/8897/8997\"\n  27:\t\tdepends on MWIFIEX \u0026\u0026 PCI\n  28:\t\tselect FW_LOADER\n  29:\t\tselect WANT_DEV_COREDUMP\n  30:\t\thelp\n  31:\t\t  This adds support for wireless adapters based on Marvell\n  32:\t\t  8766/8897/8997 chipsets with PCIe interface.\n  33:\t\n  34:\t\t  If you choose to build it as a module, it will be called\n  35:\t\t  mwifiex_pcie.\n  36:\t\n  37:\tconfig MWIFIEX_USB\n  38:\t\ttristate \"Marvell WiFi-Ex Driver for USB8766/8797/8997\"\n  39:\t\tdepends on MWIFIEX \u0026\u0026 USB\n  40:\t\tselect FW_LOADER\n  41:\t\thelp\n  42:\t\t  This adds support for wireless adapters based on Marvell\n  43:\t\t  8797/8997 chipset with USB interface.\n  44:\t\n  45:\t\t  If you choose to build it as a module, it will be called\n  46:\t\t  mwifiex_usb.\n"
}

							input: 5307
							output: 45
							thoughts: 24

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

**Diving into the WMM Status Retrieval**

Alright, let's get down to brass tacks. I need to understand the control flow and potential implications of this `mwifiex_ret_wmm_get_status` function. It's time to map its call graph. Specifically, I'm interested in the contexts that trigger this retrieval and, by extension, the conditions that might affect the WMM status. I'm already anticipating areas where subtle timing issues or race conditions might surface – these WMM-related functions tend to be sensitive. The goal here isn't just to see *that* it's called, but to build a mental model of *why*, and *when* it is called, from what state is it being called from? and what events triggered the calls? This will help pinpoint any issues in QoS management, power saving features, or inter-operation with other parts of the driver. Now, let's open that source...

{
  "Expression": "mwifiex_ret_wmm_get_status",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1212=int mwifiex_process_sta_cmdresp(struct mwifiex_private *priv, u16 cmdresp_no,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1359-\tcase HostCmd_CMD_WMM_GET_STATUS:\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1360:\t\tret = mwifiex_ret_wmm_get_status(priv, resp);\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1361-\t\tbreak;\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.c=808=mwifiex_wmm_add_buf_txqueue(struct mwifiex_private *priv,\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.c-909- */\ndrivers/net/wireless/marvell/mwifiex/wmm.c:910:int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/wmm.c-911-\t\t\t       const struct host_cmd_ds_command *resp)\n--\ndrivers/net/wireless/marvell/mwifiex/wmm.h=85=void mwifiex_wmm_setup_ac_downgrade(struct mwifiex_private *priv);\ndrivers/net/wireless/marvell/mwifiex/wmm.h:86:int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/wmm.h-87-\t\t\t       const struct host_cmd_ds_command *resp);\n"
}

							input: 6065
							output: 45
							thoughts: 34

Here's my summary, as if I were thinking these thoughts:

**Analyzing the Marvell Wi-Fi WMM Implementation**

Okay, time to dive into this WMM implementation. I want to take a look at `drivers/net/wireless/marvell/mwifiex/wmm.c` – specifically, I'm focusing on the code around line 910 to 960. I need to get a better handle on how they're handling that specific part of the WMM functionality. Probably something about queue management or contention mechanisms, but I need to see it in action to know for sure. Let’s get to it. I want to see how Marvell's handling the WMM standard, and what potential optimizations or issues might be there.

{
  "File": "drivers/net/wireless/marvell/mwifiex/wmm.c",
  "FirstLine": 905,
  "LineCount": 70
}

{
  "Contents": " 905:\t *      - Admission Control action frame TLVs\n 906:\t *\n 907:\t * This function parses the TLVs and then calls further specific functions\n 908:\t * to process any changes in the queue prioritize or state.\n 909:\t */\n 910:\tint mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\n 911:\t\t\t\t       const struct host_cmd_ds_command *resp)\n 912:\t{\n 913:\t\tu8 *curr = (u8 *) \u0026resp-\u003eparams.get_wmm_status;\n 914:\t\tuint16_t resp_len = le16_to_cpu(resp-\u003esize), tlv_len;\n 915:\t\tint mask = IEEE80211_WMM_IE_AP_QOSINFO_PARAM_SET_CNT_MASK;\n 916:\t\tbool valid = true;\n 917:\t\n 918:\t\tstruct mwifiex_ie_types_data *tlv_hdr;\n 919:\t\tstruct mwifiex_ie_types_wmm_queue_status *tlv_wmm_qstatus;\n 920:\t\tstruct ieee_types_wmm_parameter *wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status *ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t    \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t    resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data *) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status *)\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 940:\t\t\t\t\t    \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 941:\t\t\t\t\t    \"QSTATUS TLV: %d, %d, %d\\n\",\n 942:\t\t\t\t\t    tlv_wmm_qstatus-\u003equeue_index,\n 943:\t\t\t\t\t    tlv_wmm_qstatus-\u003eflow_required,\n 944:\t\t\t\t\t    tlv_wmm_qstatus-\u003edisabled);\n 945:\t\n 946:\t\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n 947:\t\t\t\t\tbreak;\n 948:\t\t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n 949:\t\t\t\t\t\t\t\t queue_index];\n 950:\t\t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n 951:\t\t\t\tac_status-\u003eflow_required =\n 952:\t\t\t\t\t\t\ttlv_wmm_qstatus-\u003eflow_required;\n 953:\t\t\t\tac_status-\u003eflow_created = tlv_wmm_qstatus-\u003eflow_created;\n 954:\t\t\t\tbreak;\n 955:\t\n 956:\t\t\tcase WLAN_EID_VENDOR_SPECIFIC:\n 957:\t\t\t\t/*\n 958:\t\t\t\t * Point the regular IEEE IE 2 bytes into the Marvell IE\n 959:\t\t\t\t *   and setup the IEEE IE type and length byte fields\n 960:\t\t\t\t */\n 961:\t\n 962:\t\t\t\twmm_param_ie =\n 963:\t\t\t\t\t(struct ieee_types_wmm_parameter *) (curr +\n 964:\t\t\t\t\t\t\t\t\t    2);\n 965:\t\t\t\twmm_param_ie-\u003evend_hdr.len = (u8) tlv_len;\n 966:\t\t\t\twmm_param_ie-\u003evend_hdr.element_id =\n 967:\t\t\t\t\t\t\tWLAN_EID_VENDOR_SPECIFIC;\n 968:\t\n 969:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 970:\t\t\t\t\t    \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 971:\t\t\t\t\t    \"WMM Parameter Set Count: %d\\n\",\n 972:\t\t\t\t\t    wmm_param_ie-\u003eqos_info_bitmap \u0026 mask);\n 973:\t\n 974:\t\t\t\tif (wmm_param_ie-\u003evend_hdr.len + 2 \u003e\n"
}

							input: 7616
							output: 29
							thoughts: 459

**Analyzing the Fuzzing Potential of a Bounds Check**

Okay, let's break this down. We've got a new patch that introduces a bounds check: `if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS) break;`. The purpose of this seems pretty clear – to stop out-of-bounds access to `priv->wmm.ac_status`. But the question is: is this even *reachable* and therefore fuzzable? The triage guidelines make that the absolute priority. If it's unreachable in a standard virtualized environment (think GCE or QEMU with emulated devices), we're wasting our time. No fuzzing.

My initial thought is that `mwifiex` has some potential. It's a USB driver, `MWIFIEX_USB`, and that’s interesting because it's emulatable using USB raw gadget or vHCI – Syzkaller specifically has USB raw gadget support for wifi drivers, and *mwifiex* is a USB wifi driver. This means we can inject firmware command responses through USB bulk or interrupt endpoints. That's a definite plus.

Now, let's confirm the configurations and dependencies. I need to make sure `MWIFIEX_USB` is correctly configured and that all the right symbols are available. The Kconfig dependencies look like this: `MWIFIEX` depends on `CFG80211`, and `MWIFIEX_USB` depends on `MWIFIEX && USB` and selects `FW_LOADER`. That looks right, but let's do a quick grep search to confirm. I should scan `drivers/net/wireless/marvell/Kconfig` and `drivers/net/wireless/Kconfig` for `MWIFIEX` to make sure there are no other configurations or dependencies that might bite us later. Just to be thorough.

{
  "Expression": "mwifiex",
  "PathPrefix": "drivers/net/wireless/"
}

{
  "Output": "\nFull output is too long, showing 500 out of 18546 lines.\nUse more precise expression if possible.\n\ndrivers/net/wireless/marvell/Kconfig=16=source \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:17:source \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig-18-\n--\ndrivers/net/wireless/marvell/Makefile=4=obj-$(CONFIG_LIBERTAS_THINFIRM)\t+= libertas_tf/\ndrivers/net/wireless/marvell/Makefile:5:obj-$(CONFIG_MWIFIEX)\t+= mwifiex/\ndrivers/net/wireless/marvell/Makefile-6-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c=42=static u16\ndrivers/net/wireless/marvell/mwifiex/11ac.c:43:mwifiex_convert_mcsmap_to_maxrate(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-44-\t\t\t\t  u8 bands, u16 mcs_map)\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-48-\tu32 usr_vht_cap_info = 0;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:49:\tstruct mwifiex_adapter *adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-50-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c=85=static void\ndrivers/net/wireless/marvell/mwifiex/11ac.c:86:mwifiex_fill_vht_cap_info(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-87-\t\t\t  struct ieee80211_vht_cap *vht_cap, u8 bands)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-88-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:89:\tstruct mwifiex_adapter *adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-90-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-98-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:99:void mwifiex_fill_vht_cap_tlv(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-100-\t\t\t      struct ieee80211_vht_cap *vht_cap, u8 bands)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-101-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:102:\tstruct mwifiex_adapter *adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-103-\tu16 mcs_map_user, mcs_map_resp, mcs_map_result;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-106-\t/* Fill VHT cap info */\ndrivers/net/wireless/marvell/mwifiex/11ac.c:107:\tmwifiex_fill_vht_cap_info(priv, vht_cap, bands);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-108-\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-128-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:129:\ttmp = mwifiex_convert_mcsmap_to_maxrate(priv, bands, mcs_map_result);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-130-\tvht_cap-\u003esupp_mcs.rx_highest = cpu_to_le16(tmp);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-150-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:151:\ttmp = mwifiex_convert_mcsmap_to_maxrate(priv, bands, mcs_map_result);\ndrivers/net/wireless/marvell/mwifiex/11ac.c-152-\tvht_cap-\u003esupp_mcs.tx_highest = cpu_to_le16(tmp);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-156-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:157:int mwifiex_cmd_append_11ac_tlv(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c:158:\t\t\t     struct mwifiex_bssdescriptor *bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-159-\t\t\t     u8 **buffer)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-160-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:161:\tstruct mwifiex_ie_types_vhtcap *vht_cap;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:162:\tstruct mwifiex_ie_types_oper_mode_ntf *oper_ntf;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-163-\tstruct ieee_types_oper_mode_ntf *ieee_oper_ntf;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:164:\tstruct mwifiex_ie_types_vht_oper *vht_op;\ndrivers/net/wireless/marvell/mwifiex/11ac.c:165:\tstruct mwifiex_adapter *adapter = priv-\u003eadapter;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-166-\tu8 supp_chwd_set;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-176-\tif (bss_desc-\u003ebcn_vht_cap) {\ndrivers/net/wireless/marvell/mwifiex/11ac.c:177:\t\tvht_cap = (struct mwifiex_ie_types_vhtcap *)*buffer;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-178-\t\tmemset(vht_cap, 0, sizeof(*vht_cap));\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-181-\t\t\t\tcpu_to_le16(sizeof(struct ieee80211_vht_cap));\ndrivers/net/wireless/marvell/mwifiex/11ac.c:182:\t\tmemcpy((u8 *)vht_cap + sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11ac.c-183-\t\t       (u8 *)bss_desc-\u003ebcn_vht_cap,\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-185-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:186:\t\tmwifiex_fill_vht_cap_tlv(priv, \u0026vht_cap-\u003evht_cap,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-187-\t\t\t\t\t bss_desc-\u003ebss_band);\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-194-\t\tif (priv-\u003ebss_mode == NL80211_IFTYPE_STATION) {\ndrivers/net/wireless/marvell/mwifiex/11ac.c:195:\t\t\tvht_op = (struct mwifiex_ie_types_vht_oper *)*buffer;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-196-\t\t\tmemset(vht_op, 0, sizeof(*vht_op));\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-199-\t\t\tvht_op-\u003eheader.len  = cpu_to_le16(sizeof(*vht_op) -\ndrivers/net/wireless/marvell/mwifiex/11ac.c:200:\t\t\t\t      sizeof(struct mwifiex_ie_types_header));\ndrivers/net/wireless/marvell/mwifiex/11ac.c-201-\t\t\tmemcpy((u8 *)vht_op +\ndrivers/net/wireless/marvell/mwifiex/11ac.c:202:\t\t\t\tsizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11ac.c-203-\t\t\t       (u8 *)bss_desc-\u003ebcn_vht_oper,\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-252-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:253:int mwifiex_cmd_11ac_cfg(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-254-\t\t\t struct host_cmd_ds_command *cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11ac.c:255:\t\t\t struct mwifiex_11ac_vht_cfg *cfg)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-256-{\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-272-/* This function initializes the BlockACK setup information for given\ndrivers/net/wireless/marvell/mwifiex/11ac.c:273: * mwifiex_private structure for 11ac enabled networks.\ndrivers/net/wireless/marvell/mwifiex/11ac.c-274- */\ndrivers/net/wireless/marvell/mwifiex/11ac.c:275:void mwifiex_set_11ac_ba_params(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-276-{\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-293-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:294:bool mwifiex_is_bss_in_11ac_mode(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11ac.c-295-{\ndrivers/net/wireless/marvell/mwifiex/11ac.c:296:\tstruct mwifiex_bssdescriptor *bss_desc;\ndrivers/net/wireless/marvell/mwifiex/11ac.c-297-\tstruct ieee80211_vht_operation *vht_oper;\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.c-310-\ndrivers/net/wireless/marvell/mwifiex/11ac.c:311:u8 mwifiex_get_center_freq_index(struct mwifiex_private *priv, u8 band,\ndrivers/net/wireless/marvell/mwifiex/11ac.c-312-\t\t\t\t u32 pri_chan, u8 chan_bw)\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.h=14=enum vht_cfg_misc_config {\n--\ndrivers/net/wireless/marvell/mwifiex/11ac.h-24-\ndrivers/net/wireless/marvell/mwifiex/11ac.h:25:int mwifiex_cmd_append_11ac_tlv(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h:26:\t\t\t\tstruct mwifiex_bssdescriptor *bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-27-\t\t\t\tu8 **buffer);\ndrivers/net/wireless/marvell/mwifiex/11ac.h:28:int mwifiex_cmd_11ac_cfg(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-29-\t\t\t struct host_cmd_ds_command *cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11ac.h:30:\t\t\t struct mwifiex_11ac_vht_cfg *cfg);\ndrivers/net/wireless/marvell/mwifiex/11ac.h:31:void mwifiex_fill_vht_cap_tlv(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11ac.h-32-\t\t\t      struct ieee80211_vht_cap *vht_cap, u8 bands);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-11-\ndrivers/net/wireless/marvell/mwifiex/11h.c:12:void mwifiex_init_11h_params(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-13-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-17-\ndrivers/net/wireless/marvell/mwifiex/11h.c:18:inline int mwifiex_is_11h_active(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-19-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c=25=static void\ndrivers/net/wireless/marvell/mwifiex/11h.c:26:mwifiex_11h_process_infra_join(struct mwifiex_private *priv, u8 **buffer,\ndrivers/net/wireless/marvell/mwifiex/11h.c:27:\t\t\t       struct mwifiex_bssdescriptor *bss_desc)\ndrivers/net/wireless/marvell/mwifiex/11h.c-28-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:29:\tstruct mwifiex_ie_types_header *ie_header;\ndrivers/net/wireless/marvell/mwifiex/11h.c:30:\tstruct mwifiex_ie_types_pwr_capability *cap;\ndrivers/net/wireless/marvell/mwifiex/11h.c:31:\tstruct mwifiex_ie_types_local_pwr_constraint *constraint;\ndrivers/net/wireless/marvell/mwifiex/11h.c-32-\tstruct ieee80211_supported_band *sband;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-38-\ndrivers/net/wireless/marvell/mwifiex/11h.c:39:\tradio_type = mwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11h.c-40-\tsband = priv-\u003ewdev.wiphy-\u003ebands[radio_type];\ndrivers/net/wireless/marvell/mwifiex/11h.c-41-\ndrivers/net/wireless/marvell/mwifiex/11h.c:42:\tcap = (struct mwifiex_ie_types_pwr_capability *)*buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-43-\tcap-\u003eheader.type = cpu_to_le16(WLAN_EID_PWR_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-48-\ndrivers/net/wireless/marvell/mwifiex/11h.c:49:\tconstraint = (struct mwifiex_ie_types_local_pwr_constraint *)*buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-50-\tconstraint-\u003eheader.type = cpu_to_le16(WLAN_EID_PWR_CONSTRAINT);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-55-\ndrivers/net/wireless/marvell/mwifiex/11h.c:56:\tie_header = (struct mwifiex_ie_types_header *)*buffer;\ndrivers/net/wireless/marvell/mwifiex/11h.c-57-\tie_header-\u003etype = cpu_to_le16(TLV_TYPE_PASSTHROUGH);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-69-/* Enable or disable the 11h extensions in the firmware */\ndrivers/net/wireless/marvell/mwifiex/11h.c:70:int mwifiex_11h_activate(struct mwifiex_private *priv, bool flag)\ndrivers/net/wireless/marvell/mwifiex/11h.c-71-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-77-\ndrivers/net/wireless/marvell/mwifiex/11h.c:78:\treturn mwifiex_send_cmd(priv, HostCmd_CMD_802_11_SNMP_MIB,\ndrivers/net/wireless/marvell/mwifiex/11h.c-79-\t\t\t\tHostCmd_ACT_GEN_SET, DOT11H_I, \u0026enable, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-87- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:88:void mwifiex_11h_process_join(struct mwifiex_private *priv, u8 **buffer,\ndrivers/net/wireless/marvell/mwifiex/11h.c:89:\t\t\t      struct mwifiex_bssdescriptor *bss_desc)\ndrivers/net/wireless/marvell/mwifiex/11h.c-90-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-94-\t\t */\ndrivers/net/wireless/marvell/mwifiex/11h.c:95:\t\tmwifiex_11h_activate(priv, true);\ndrivers/net/wireless/marvell/mwifiex/11h.c-96-\t\tpriv-\u003estate_11h.is_11h_active = true;\ndrivers/net/wireless/marvell/mwifiex/11h.c-97-\t\tbss_desc-\u003ecap_info_bitmap |= WLAN_CAPABILITY_SPECTRUM_MGMT;\ndrivers/net/wireless/marvell/mwifiex/11h.c:98:\t\tmwifiex_11h_process_infra_join(priv, buffer, bss_desc);\ndrivers/net/wireless/marvell/mwifiex/11h.c-99-\t} else {\ndrivers/net/wireless/marvell/mwifiex/11h.c-100-\t\t/* Deactivate 11h functions in the firmware */\ndrivers/net/wireless/marvell/mwifiex/11h.c:101:\t\tmwifiex_11h_activate(priv, false);\ndrivers/net/wireless/marvell/mwifiex/11h.c-102-\t\tpriv-\u003estate_11h.is_11h_active = false;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-110- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:111:void mwifiex_dfs_cac_work_queue(struct work_struct *work)\ndrivers/net/wireless/marvell/mwifiex/11h.c-112-{\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-114-\tstruct delayed_work *delayed_work = to_delayed_work(work);\ndrivers/net/wireless/marvell/mwifiex/11h.c:115:\tstruct mwifiex_private *priv =\ndrivers/net/wireless/marvell/mwifiex/11h.c:116:\t\t\tcontainer_of(delayed_work, struct mwifiex_private,\ndrivers/net/wireless/marvell/mwifiex/11h.c-117-\t\t\t\t     dfs_cac_work);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-120-\tif (priv-\u003ewdev.links[0].cac_started) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:121:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-122-\t\t\t    \"CAC timer finished; No radar detected\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-131- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:132:int mwifiex_cmd_issue_chan_report_request(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-133-\t\t\t\t\t  struct host_cmd_ds_command *cmd,\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-136-\tstruct host_cmd_ds_chan_rpt_req *cr_req = \u0026cmd-\u003eparams.chan_rpt_req;\ndrivers/net/wireless/marvell/mwifiex/11h.c:137:\tstruct mwifiex_radar_params *radar_params = (void *)data_buf;\ndrivers/net/wireless/marvell/mwifiex/11h.c-138-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-149-\tif (radar_params-\u003ecac_time_ms)\ndrivers/net/wireless/marvell/mwifiex/11h.c:150:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-151-\t\t\t    \"11h: issuing DFS Radar check for channel=%d\\n\",\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-153-\telse\ndrivers/net/wireless/marvell/mwifiex/11h.c:154:\t\tmwifiex_dbg(priv-\u003eadapter, MSG, \"cancelling CAC\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c-155-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-158-\ndrivers/net/wireless/marvell/mwifiex/11h.c:159:int mwifiex_stop_radar_detection(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-160-\t\t\t\t struct cfg80211_chan_def *chandef)\ndrivers/net/wireless/marvell/mwifiex/11h.c-161-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:162:\tstruct mwifiex_radar_params radar_params;\ndrivers/net/wireless/marvell/mwifiex/11h.c-163-\ndrivers/net/wireless/marvell/mwifiex/11h.c:164:\tmemset(\u0026radar_params, 0, sizeof(struct mwifiex_radar_params));\ndrivers/net/wireless/marvell/mwifiex/11h.c-165-\tradar_params.chandef = chandef;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-167-\ndrivers/net/wireless/marvell/mwifiex/11h.c:168:\treturn mwifiex_send_cmd(priv, HostCmd_CMD_CHAN_REPORT_REQUEST,\ndrivers/net/wireless/marvell/mwifiex/11h.c-169-\t\t\t\tHostCmd_ACT_GEN_SET, 0, \u0026radar_params, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-174- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:175:void mwifiex_abort_cac(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11h.c-176-{\ndrivers/net/wireless/marvell/mwifiex/11h.c-177-\tif (priv-\u003ewdev.links[0].cac_started) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:178:\t\tif (mwifiex_stop_radar_detection(priv, \u0026priv-\u003edfs_chandef))\ndrivers/net/wireless/marvell/mwifiex/11h.c:179:\t\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-180-\t\t\t\t    \"failed to stop CAC in FW\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c:181:\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-182-\t\t\t    \"Aborting delayed work for CAC.\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-193- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:194:int mwifiex_11h_handle_chanrpt_ready(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-195-\t\t\t\t     struct sk_buff *skb)\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-197-\tstruct host_cmd_ds_chan_rpt_event *rpt_event;\ndrivers/net/wireless/marvell/mwifiex/11h.c:198:\tstruct mwifiex_ie_types_chan_rpt_data *rpt;\ndrivers/net/wireless/marvell/mwifiex/11h.c-199-\tu16 event_len, tlv_len;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-205-\tif (le32_to_cpu(rpt_event-\u003eresult) != HostCmd_RESULT_OK) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:206:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-207-\t\t\t    \"Error in channel report event\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-210-\ndrivers/net/wireless/marvell/mwifiex/11h.c:211:\twhile (event_len \u003e= sizeof(struct mwifiex_ie_types_header)) {\ndrivers/net/wireless/marvell/mwifiex/11h.c-212-\t\trpt = (void *)\u0026rpt_event-\u003etlvbuf;\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-217-\t\t\tif (rpt-\u003emap.radar) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:218:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-219-\t\t\t\t\t    \"RADAR Detected on channel %d!\\n\",\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-238-/* Handler for radar detected event from FW.*/\ndrivers/net/wireless/marvell/mwifiex/11h.c:239:int mwifiex_11h_handle_radar_detected(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11h.c-240-\t\t\t\t      struct sk_buff *skb)\ndrivers/net/wireless/marvell/mwifiex/11h.c-241-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:242:\tstruct mwifiex_radar_det_event *rdr_event;\ndrivers/net/wireless/marvell/mwifiex/11h.c-243-\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-245-\ndrivers/net/wireless/marvell/mwifiex/11h.c:246:\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-247-\t\t    \"radar detected; indicating kernel\\n\");\ndrivers/net/wireless/marvell/mwifiex/11h.c:248:\tif (mwifiex_stop_radar_detection(priv, \u0026priv-\u003edfs_chandef))\ndrivers/net/wireless/marvell/mwifiex/11h.c:249:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-250-\t\t\t    \"Failed to stop CAC in FW\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-252-\t\t\t     GFP_KERNEL);\ndrivers/net/wireless/marvell/mwifiex/11h.c:253:\tmwifiex_dbg(priv-\u003eadapter, MSG, \"regdomain: %d\\n\",\ndrivers/net/wireless/marvell/mwifiex/11h.c-254-\t\t    rdr_event-\u003ereg_domain);\ndrivers/net/wireless/marvell/mwifiex/11h.c:255:\tmwifiex_dbg(priv-\u003eadapter, MSG, \"radar detection type: %d\\n\",\ndrivers/net/wireless/marvell/mwifiex/11h.c-256-\t\t    rdr_event-\u003edet_type);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-265- */\ndrivers/net/wireless/marvell/mwifiex/11h.c:266:void mwifiex_dfs_chan_sw_work_queue(struct work_struct *work)\ndrivers/net/wireless/marvell/mwifiex/11h.c-267-{\ndrivers/net/wireless/marvell/mwifiex/11h.c:268:\tstruct mwifiex_uap_bss_param *bss_cfg;\ndrivers/net/wireless/marvell/mwifiex/11h.c-269-\tstruct delayed_work *delayed_work = to_delayed_work(work);\ndrivers/net/wireless/marvell/mwifiex/11h.c:270:\tstruct mwifiex_private *priv =\ndrivers/net/wireless/marvell/mwifiex/11h.c:271:\t\t\tcontainer_of(delayed_work, struct mwifiex_private,\ndrivers/net/wireless/marvell/mwifiex/11h.c-272-\t\t\t\t     dfs_chan_sw_work);\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-275-\tif (!bss_cfg-\u003ebeacon_period) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:276:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-277-\t\t\t    \"channel switch: AP already stopped\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-280-\ndrivers/net/wireless/marvell/mwifiex/11h.c:281:\tmwifiex_uap_set_channel(priv, bss_cfg, priv-\u003edfs_chandef);\ndrivers/net/wireless/marvell/mwifiex/11h.c-282-\ndrivers/net/wireless/marvell/mwifiex/11h.c:283:\tif (mwifiex_config_start_uap(priv, bss_cfg)) {\ndrivers/net/wireless/marvell/mwifiex/11h.c:284:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR,\ndrivers/net/wireless/marvell/mwifiex/11h.c-285-\t\t\t    \"Failed to start AP after channel switch\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11h.c-288-\ndrivers/net/wireless/marvell/mwifiex/11h.c:289:\tmwifiex_dbg(priv-\u003eadapter, MSG,\ndrivers/net/wireless/marvell/mwifiex/11h.c-290-\t\t    \"indicating channel switch completion to kernel\\n\");\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-24- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:25:int mwifiex_fill_cap_info(struct mwifiex_private *priv, u8 radio_type,\ndrivers/net/wireless/marvell/mwifiex/11n.c-26-\t\t\t  struct ieee80211_ht_cap *ht_cap)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-32-\tif (WARN_ON_ONCE(!sband)) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:33:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR, \"Invalid radio type!\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-34-\t\treturn -EINVAL;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-69- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:70:static struct mwifiex_tx_ba_stream_tbl *\ndrivers/net/wireless/marvell/mwifiex/11n.c:71:mwifiex_get_ba_status(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:72:\t\t      enum mwifiex_ba_status ba_status)\ndrivers/net/wireless/marvell/mwifiex/11n.c-73-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:74:\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-75-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-95- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:96:int mwifiex_ret_11n_delba(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-97-\t\t\t  struct host_cmd_ds_command *resp)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-99-\tint tid;\ndrivers/net/wireless/marvell/mwifiex/11n.c:100:\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-101-\tstruct host_cmd_ds_11n_delba *del_ba = \u0026resp-\u003eparams.del_ba;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-105-\tif (del_ba-\u003edel_result == BA_RESULT_SUCCESS) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:106:\t\tmwifiex_del_ba_tbl(priv, tid, del_ba-\u003epeer_mac_addr,\ndrivers/net/wireless/marvell/mwifiex/11n.c-107-\t\t\t\t   TYPE_DELBA_SENT,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-109-\ndrivers/net/wireless/marvell/mwifiex/11n.c:110:\t\ttx_ba_tbl = mwifiex_get_ba_status(priv, BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-111-\t\tif (tx_ba_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c:112:\t\t\tmwifiex_send_addba(priv, tx_ba_tbl-\u003etid,\ndrivers/net/wireless/marvell/mwifiex/11n.c-113-\t\t\t\t\t   tx_ba_tbl-\u003era);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-120-\ndrivers/net/wireless/marvell/mwifiex/11n.c:121:\t\tmwifiex_create_ba_tbl(priv, del_ba-\u003epeer_mac_addr, tid,\ndrivers/net/wireless/marvell/mwifiex/11n.c-122-\t\t\t\t      BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-123-\ndrivers/net/wireless/marvell/mwifiex/11n.c:124:\t\ttx_ba_tbl = mwifiex_get_ba_status(priv, BA_SETUP_INPROGRESS);\ndrivers/net/wireless/marvell/mwifiex/11n.c-125-\ndrivers/net/wireless/marvell/mwifiex/11n.c-126-\t\tif (tx_ba_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c:127:\t\t\tmwifiex_del_ba_tbl(priv, tx_ba_tbl-\u003etid, tx_ba_tbl-\u003era,\ndrivers/net/wireless/marvell/mwifiex/11n.c-128-\t\t\t\t\t   TYPE_DELBA_SENT, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-141- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:142:int mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-143-\t\t\t      struct host_cmd_ds_command *resp)\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-146-\tstruct host_cmd_ds_11n_addba_rsp *add_ba_rsp = \u0026resp-\u003eparams.add_ba_rsp;\ndrivers/net/wireless/marvell/mwifiex/11n.c:147:\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c:148:\tstruct mwifiex_ra_list_tbl *ra_list;\ndrivers/net/wireless/marvell/mwifiex/11n.c-149-\tu16 block_ack_param_set = le16_to_cpu(add_ba_rsp-\u003eblock_ack_param_set);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-156-\ndrivers/net/wireless/marvell/mwifiex/11n.c:157:\ttid_down = mwifiex_wmm_downgrade_tid(priv, tid);\ndrivers/net/wireless/marvell/mwifiex/11n.c:158:\tra_list = mwifiex_wmm_get_ralist_node(priv, tid_down, add_ba_rsp-\u003e\ndrivers/net/wireless/marvell/mwifiex/11n.c-159-\t\tpeer_mac_addr);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-164-\t\t}\ndrivers/net/wireless/marvell/mwifiex/11n.c:165:\t\tmwifiex_del_ba_tbl(priv, tid, add_ba_rsp-\u003epeer_mac_addr,\ndrivers/net/wireless/marvell/mwifiex/11n.c-166-\t\t\t\t   TYPE_DELBA_SENT, true);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-172-\ndrivers/net/wireless/marvell/mwifiex/11n.c:173:\ttx_ba_tbl = mwifiex_get_ba_tbl(priv, tid, add_ba_rsp-\u003epeer_mac_addr);\ndrivers/net/wireless/marvell/mwifiex/11n.c-174-\tif (tx_ba_tbl) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:175:\t\tmwifiex_dbg(priv-\u003eadapter, EVENT, \"info: BA stream complete\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-176-\t\ttx_ba_tbl-\u003eba_status = BA_SETUP_COMPLETE;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-187-\t} else {\ndrivers/net/wireless/marvell/mwifiex/11n.c:188:\t\tmwifiex_dbg(priv-\u003eadapter, ERROR, \"BA stream not created\\n\");\ndrivers/net/wireless/marvell/mwifiex/11n.c-189-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-201- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:202:int mwifiex_cmd_recfg_tx_buf(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-203-\t\t\t     struct host_cmd_ds_command *cmd, int cmd_action,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-214-\tcase HostCmd_ACT_GEN_SET:\ndrivers/net/wireless/marvell/mwifiex/11n.c:215:\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\ndrivers/net/wireless/marvell/mwifiex/11n.c-216-\t\t\t    \"cmd: set tx_buf=%d\\n\", *buf_size);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-234- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:235:int mwifiex_cmd_amsdu_aggr_ctrl(struct host_cmd_ds_command *cmd,\ndrivers/net/wireless/marvell/mwifiex/11n.c-236-\t\t\t\tint cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11n.c:237:\t\t\t\tstruct mwifiex_ds_11n_amsdu_aggr_ctrl *aa_ctrl)\ndrivers/net/wireless/marvell/mwifiex/11n.c-238-{\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-267- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:268:int mwifiex_cmd_11n_cfg(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c-269-\t\t\tstruct host_cmd_ds_command *cmd, u16 cmd_action,\ndrivers/net/wireless/marvell/mwifiex/11n.c:270:\t\t\tstruct mwifiex_ds_11n_tx_cfg *txcfg)\ndrivers/net/wireless/marvell/mwifiex/11n.c-271-{\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c=298=int\ndrivers/net/wireless/marvell/mwifiex/11n.c:299:mwifiex_cmd_append_11n_tlv(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:300:\t\t\t   struct mwifiex_bssdescriptor *bss_desc,\ndrivers/net/wireless/marvell/mwifiex/11n.c-301-\t\t\t   u8 **buffer)\ndrivers/net/wireless/marvell/mwifiex/11n.c-302-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:303:\tstruct mwifiex_ie_types_htcap *ht_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c:304:\tstruct mwifiex_ie_types_htinfo *ht_info;\ndrivers/net/wireless/marvell/mwifiex/11n.c:305:\tstruct mwifiex_ie_types_chan_list_param_set *chan_list;\ndrivers/net/wireless/marvell/mwifiex/11n.c:306:\tstruct mwifiex_ie_types_2040bssco *bss_co_2040;\ndrivers/net/wireless/marvell/mwifiex/11n.c:307:\tstruct mwifiex_ie_types_extcap *ext_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c-308-\tint ret_len = 0;\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-315-\ndrivers/net/wireless/marvell/mwifiex/11n.c:316:\tradio_type = mwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-317-\tsband = priv-\u003ewdev.wiphy-\u003ebands[radio_type];\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-319-\tif (bss_desc-\u003ebcn_ht_cap) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:320:\t\tht_cap = (struct mwifiex_ie_types_htcap *) *buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c:321:\t\tmemset(ht_cap, 0, sizeof(struct mwifiex_ie_types_htcap));\ndrivers/net/wireless/marvell/mwifiex/11n.c-322-\t\tht_cap-\u003eheader.type = cpu_to_le16(WLAN_EID_HT_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-324-\t\t\t\tcpu_to_le16(sizeof(struct ieee80211_ht_cap));\ndrivers/net/wireless/marvell/mwifiex/11n.c:325:\t\tmemcpy((u8 *) ht_cap + sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-326-\t\t       (u8 *)bss_desc-\u003ebcn_ht_cap,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-328-\ndrivers/net/wireless/marvell/mwifiex/11n.c:329:\t\tmwifiex_fill_cap_info(priv, radio_type, \u0026ht_cap-\u003eht_cap);\ndrivers/net/wireless/marvell/mwifiex/11n.c-330-\t\t/* Update HT40 capability from current channel information */\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-333-\t\t\tu8 radio =\ndrivers/net/wireless/marvell/mwifiex/11n.c:334:\t\t\tmwifiex_band_to_radio_type(bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-335-\t\t\tint freq =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-362-\ndrivers/net/wireless/marvell/mwifiex/11n.c:363:\t\t*buffer += sizeof(struct mwifiex_ie_types_htcap);\ndrivers/net/wireless/marvell/mwifiex/11n.c:364:\t\tret_len += sizeof(struct mwifiex_ie_types_htcap);\ndrivers/net/wireless/marvell/mwifiex/11n.c-365-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-368-\t\tif (priv-\u003ebss_mode == NL80211_IFTYPE_ADHOC) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:369:\t\t\tht_info = (struct mwifiex_ie_types_htinfo *) *buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-370-\t\t\tmemset(ht_info, 0,\ndrivers/net/wireless/marvell/mwifiex/11n.c:371:\t\t\t       sizeof(struct mwifiex_ie_types_htinfo));\ndrivers/net/wireless/marvell/mwifiex/11n.c-372-\t\t\tht_info-\u003eheader.type =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-378-\t\t\tmemcpy((u8 *) ht_info +\ndrivers/net/wireless/marvell/mwifiex/11n.c:379:\t\t\t       sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-380-\t\t\t       (u8 *)bss_desc-\u003ebcn_ht_oper,\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-388-\ndrivers/net/wireless/marvell/mwifiex/11n.c:389:\t\t\t*buffer += sizeof(struct mwifiex_ie_types_htinfo);\ndrivers/net/wireless/marvell/mwifiex/11n.c:390:\t\t\tret_len += sizeof(struct mwifiex_ie_types_htinfo);\ndrivers/net/wireless/marvell/mwifiex/11n.c-391-\t\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-393-\t\tchan_list =\ndrivers/net/wireless/marvell/mwifiex/11n.c:394:\t\t\t(struct mwifiex_ie_types_chan_list_param_set *) *buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-395-\t\tmemset(chan_list, 0, struct_size(chan_list, chan_scan_param, 1));\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-397-\t\tchan_list-\u003eheader.len =\ndrivers/net/wireless/marvell/mwifiex/11n.c:398:\t\t\tcpu_to_le16(sizeof(struct mwifiex_chan_scan_param_set));\ndrivers/net/wireless/marvell/mwifiex/11n.c-399-\t\tchan_list-\u003echan_scan_param[0].chan_number =\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-401-\t\tchan_list-\u003echan_scan_param[0].radio_type =\ndrivers/net/wireless/marvell/mwifiex/11n.c:402:\t\t\tmwifiex_band_to_radio_type((u8) bss_desc-\u003ebss_band);\ndrivers/net/wireless/marvell/mwifiex/11n.c-403-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-416-\tif (bss_desc-\u003ebcn_bss_co_2040) {\ndrivers/net/wireless/marvell/mwifiex/11n.c:417:\t\tbss_co_2040 = (struct mwifiex_ie_types_2040bssco *) *buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c-418-\t\tmemset(bss_co_2040, 0,\ndrivers/net/wireless/marvell/mwifiex/11n.c:419:\t\t       sizeof(struct mwifiex_ie_types_2040bssco));\ndrivers/net/wireless/marvell/mwifiex/11n.c-420-\t\tbss_co_2040-\u003eheader.type = cpu_to_le16(WLAN_EID_BSS_COEX_2040);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-424-\t\tmemcpy((u8 *) bss_co_2040 +\ndrivers/net/wireless/marvell/mwifiex/11n.c:425:\t\t       sizeof(struct mwifiex_ie_types_header),\ndrivers/net/wireless/marvell/mwifiex/11n.c-426-\t\t       bss_desc-\u003ebcn_bss_co_2040 +\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-429-\ndrivers/net/wireless/marvell/mwifiex/11n.c:430:\t\t*buffer += sizeof(struct mwifiex_ie_types_2040bssco);\ndrivers/net/wireless/marvell/mwifiex/11n.c:431:\t\tret_len += sizeof(struct mwifiex_ie_types_2040bssco);\ndrivers/net/wireless/marvell/mwifiex/11n.c-432-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-435-\t\thdr = (void *)bss_desc-\u003ebcn_ext_cap;\ndrivers/net/wireless/marvell/mwifiex/11n.c:436:\t\text_cap = (struct mwifiex_ie_types_extcap *) *buffer;\ndrivers/net/wireless/marvell/mwifiex/11n.c:437:\t\tmemset(ext_cap, 0, sizeof(struct mwifiex_ie_types_extcap));\ndrivers/net/wireless/marvell/mwifiex/11n.c-438-\t\text_cap-\u003eheader.type = cpu_to_le16(WLAN_EID_EXT_CAPABILITY);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-450-\ndrivers/net/wireless/marvell/mwifiex/11n.c:451:\t\t*buffer += sizeof(struct mwifiex_ie_types_extcap) + hdr-\u003elen;\ndrivers/net/wireless/marvell/mwifiex/11n.c:452:\t\tret_len += sizeof(struct mwifiex_ie_types_extcap) + hdr-\u003elen;\ndrivers/net/wireless/marvell/mwifiex/11n.c-453-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-461- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:462:static int mwifiex_is_tx_ba_stream_ptr_valid(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:463:\t\t\t\tstruct mwifiex_tx_ba_stream_tbl *tx_tbl_ptr)\ndrivers/net/wireless/marvell/mwifiex/11n.c-464-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:465:\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-466-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-480- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:481:void mwifiex_11n_delete_tx_ba_stream_tbl_entry(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/11n.c:482:\t\t\t\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tsr_tbl)\ndrivers/net/wireless/marvell/mwifiex/11n.c-483-{\ndrivers/net/wireless/marvell/mwifiex/11n.c-484-\tif (!tx_ba_tsr_tbl \u0026\u0026\ndrivers/net/wireless/marvell/mwifiex/11n.c:485:\t    mwifiex_is_tx_ba_stream_ptr_valid(priv, tx_ba_tsr_tbl))\ndrivers/net/wireless/marvell/mwifiex/11n.c-486-\t\treturn;\ndrivers/net/wireless/marvell/mwifiex/11n.c-487-\ndrivers/net/wireless/marvell/mwifiex/11n.c:488:\tmwifiex_dbg(priv-\u003eadapter, INFO,\ndrivers/net/wireless/marvell/mwifiex/11n.c-489-\t\t    \"info: tx_ba_tsr_tbl %p\\n\", tx_ba_tsr_tbl);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-498- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:499:void mwifiex_11n_delete_all_tx_ba_stream_tbl(struct mwifiex_private *priv)\ndrivers/net/wireless/marvell/mwifiex/11n.c-500-{\ndrivers/net/wireless/marvell/mwifiex/11n.c-501-\tint i;\ndrivers/net/wireless/marvell/mwifiex/11n.c:502:\tstruct mwifiex_tx_ba_stream_tbl *del_tbl_ptr, *tmp_node;\ndrivers/net/wireless/marvell/mwifiex/11n.c-503-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-506-\t\t\t\t \u0026priv-\u003etx_ba_stream_tbl_ptr, list)\ndrivers/net/wireless/marvell/mwifiex/11n.c:507:\t\tmwifiex_11n_delete_tx_ba_stream_tbl_entry(priv, del_tbl_ptr);\ndrivers/net/wireless/marvell/mwifiex/11n.c-508-\tspin_unlock_bh(\u0026priv-\u003etx_ba_stream_tbl_lock);\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-520- */\ndrivers/net/wireless/marvell/mwifiex/11n.c:521:struct mwifiex_tx_ba_stream_tbl *\ndrivers/net/wireless/marvell/mwifiex/11n.c:522:mwifiex_get_ba_tbl(struct mwifiex_private *priv, int tid, u8 *ra)\ndrivers/net/wireless/marvell/mwifiex/11n.c-523-{\ndrivers/net/wireless/marvell/mwifiex/11n.c:524:\tstruct mwifiex_tx_ba_stream_tbl *tx_ba_tsr_tbl;\ndrivers/net/wireless/marvell/mwifiex/11n.c-525-\n--\ndrivers/net/wireless/marvell/mwifiex/11n.c-541- */\n\n"
}

							input: 23913
							output: 37
							thoughts: 23

Here's a summary of my thought process, as requested:

**Diving into the Marvell Wireless Driver Configuration**

Okay, so I need to understand the precise configuration structure for the Marvell wireless driver. I know it's located under `drivers/net/wireless/marvell`, but the specifics are what I'm after. My plan is to jump directly into the `Kconfig` file in that directory. That's where I'll find all the conditional build options, dependencies, and descriptions related to this driver. It'll give me the exact information I need to confirm my assumptions and get a deeper understanding of the configuration. Let's see what's in there.

{
  "File": "drivers/net/wireless/marvell/Kconfig",
  "FirstLine": 1,
  "LineCount": 30
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\tconfig WLAN_VENDOR_MARVELL\n   3:\t\tbool \"Marvell devices\"\n   4:\t\tdefault y\n   5:\t\thelp\n   6:\t\t  If you have a wireless card belonging to this class, say Y.\n   7:\t\n   8:\t\t  Note that the answer to this question doesn't directly affect the\n   9:\t\t  kernel: saying N will just cause the configurator to skip all the\n  10:\t\t  questions about these cards. If you say Y, you will be asked for\n  11:\t\t  your specific card in the following questions.\n  12:\t\n  13:\tif WLAN_VENDOR_MARVELL\n  14:\t\n  15:\tsource \"drivers/net/wireless/marvell/libertas/Kconfig\"\n  16:\tsource \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\n  17:\tsource \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\n  18:\t\n  19:\tconfig MWL8K\n  20:\t\ttristate \"Marvell 88W8xxx PCI/PCIe Wireless support\"\n  21:\t\tdepends on MAC80211 \u0026\u0026 PCI\n  22:\t\thelp\n  23:\t\t  This driver supports Marvell TOPDOG 802.11 wireless cards.\n  24:\t\n  25:\t\t  To compile this driver as a module, choose M here: the module\n  26:\t\t  will be called mwl8k.  If unsure, say N.\n  27:\t\n  28:\tendif # WLAN_VENDOR_MARVELL\n"
}

							input: 24546
							output: 48
							thoughts: 68

**Analyzing the `mwifiex_ret_wmm_get_status` Function**

Okay, let's dive into this. I need to understand the calling context of `mwifiex_ret_wmm_get_status` and get a broader understanding of its place in the system. The logical first step is to trace all its callers and identify any other relevant entry points that might be in play. My intuition is that this will quickly reveal what's driving the need for this particular status retrieval.

Right, let's zero in on `drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c`, specifically around lines 1350-1370. This should provide some concrete examples of where and how the function is invoked, and what data it's dealing with in those specific scenarios. I'm expecting this section of the code to contain the critical information I need. I'm interested in the surrounding logic as much as the direct calls. This level of detail should give me a solid grasp of its purpose.

{
  "File": "drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c",
  "FirstLine": 1350,
  "LineCount": 30
}

{
  "Contents": "1350:\t\t\tmwifiex_dbg(adapter, CMD, \"cmd: curr_tx_buf_size=%d\\n\",\n1351:\t\t\t\t    adapter-\u003ecurr_tx_buf_size);\n1352:\t\n1353:\t\t\tif (adapter-\u003eif_ops.update_mp_end_port)\n1354:\t\t\t\tadapter-\u003eif_ops.update_mp_end_port(adapter,\n1355:\t\t\t\t\tle16_to_cpu(resp-\u003eparams.tx_buf.mp_end_port));\n1356:\t\t\tbreak;\n1357:\t\tcase HostCmd_CMD_AMSDU_AGGR_CTRL:\n1358:\t\t\tbreak;\n1359:\t\tcase HostCmd_CMD_WMM_GET_STATUS:\n1360:\t\t\tret = mwifiex_ret_wmm_get_status(priv, resp);\n1361:\t\t\tbreak;\n1362:\t\tcase HostCmd_CMD_802_11_IBSS_COALESCING_STATUS:\n1363:\t\t\tret = mwifiex_ret_ibss_coalescing_status(priv, resp);\n1364:\t\t\tbreak;\n1365:\t\tcase HostCmd_CMD_MEM_ACCESS:\n1366:\t\t\tret = mwifiex_ret_mem_access(priv, resp, data_buf);\n1367:\t\t\tbreak;\n1368:\t\tcase HostCmd_CMD_MAC_REG_ACCESS:\n1369:\t\tcase HostCmd_CMD_BBP_REG_ACCESS:\n1370:\t\tcase HostCmd_CMD_RF_REG_ACCESS:\n1371:\t\tcase HostCmd_CMD_PMIC_REG_ACCESS:\n1372:\t\tcase HostCmd_CMD_CAU_REG_ACCESS:\n1373:\t\tcase HostCmd_CMD_802_11_EEPROM_ACCESS:\n1374:\t\t\tret = mwifiex_ret_reg_access(cmdresp_no, resp, data_buf);\n1375:\t\t\tbreak;\n1376:\t\tcase HostCmd_CMD_SET_BSS_MODE:\n1377:\t\t\tbreak;\n1378:\t\tcase HostCmd_CMD_11N_CFG:\n1379:\t\t\tbreak;\n"
}

							input: 25467
							output: 43
							thoughts: 70

**Tracing the Execution Path**

Okay, here's what I'm thinking. I've got `mwifiex_ret_wmm_get_status` and I see that it's called by `mwifiex_process_sta_cmdresp`. My next step, as always, is to understand the calling hierarchy. I need to figure out where `mwifiex_process_sta_cmdresp` is actually invoked. So, I need to go hunt that function down with a quick search. Time to trace the execution flow and build the bigger picture.

{
  "Expression": "mwifiex_process_sta_cmdresp",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/cmdevt.c=803=int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-891-\t\t/* handle response */\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:892:\t\tret = mwifiex_process_sta_cmdresp(priv, cmdresp_no, resp);\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-893-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/main.h=1134=int mwifiex_uap_prepare_cmd(struct mwifiex_private *priv, uint16_t cmd_no,\n--\ndrivers/net/wireless/marvell/mwifiex/main.h-1136-\t\t\t    void *data_buf, void *cmd_buf);\ndrivers/net/wireless/marvell/mwifiex/main.h:1137:int mwifiex_process_sta_cmdresp(struct mwifiex_private *, u16 cmdresp_no,\ndrivers/net/wireless/marvell/mwifiex/main.h-1138-\t\t\t\tstruct host_cmd_ds_command *resp);\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1190=static int mwifiex_ret_get_chan_info(struct mwifiex_private *priv,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1211- */\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1212:int mwifiex_process_sta_cmdresp(struct mwifiex_private *priv, u16 cmdresp_no,\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1213-\t\t\t\tstruct host_cmd_ds_command *resp)\n"
}

							input: 26212
							output: 41
							thoughts: 79

Here's my thinking process:

**Diving into Command Response Handling in mwifiex**

Okay, so I'm looking at how the `mwifiex` driver processes command responses. I know that `mwifiex_process_cmdresp` is the key function here, it's the one responsible for taking those responses that are coming in from the device. Now, the question is, how are those responses *received* in the first place? My initial hunch is that it's going to be handled over USB, which means I'll need to explore the USB-specific parts of the driver.

Therefore, I'm thinking I need to zero in on the relevant receive functions. The comments point toward `mwifiex_usb_recv` and `mwifiex_usb_rx_complete`, but I need to confirm where these are invoked from. So, I need to open the source code for `mwifiex_usb.c` (or potentially `usb.c` within the `mwifiex` directory) and start tracing the data flow. That will be the next step.

{
  "Expression": "mwifiex_process_cmdresp",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/cmdevt.c=741=int mwifiex_exec_next_cmd(struct mwifiex_adapter *adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-802- */\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:803:int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter)\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-804-{\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c=1085=mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-1093-\t\t/* setting curr_cmd to NULL is quite dangerous, because\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c:1094:\t\t * mwifiex_process_cmdresp checks curr_cmd to be != NULL\ndrivers/net/wireless/marvell/mwifiex/cmdevt.c-1095-\t\t * at the beginning then relies on it and dereferences\n--\ndrivers/net/wireless/marvell/mwifiex/main.c=248=int mwifiex_main_process(struct mwifiex_adapter *adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/main.c-356-\t\t\tadapter-\u003ecmd_resp_received = false;\ndrivers/net/wireless/marvell/mwifiex/main.c:357:\t\t\tmwifiex_process_cmdresp(adapter);\ndrivers/net/wireless/marvell/mwifiex/main.c-358-\t\t}\n--\ndrivers/net/wireless/marvell/mwifiex/main.h=1100=int mwifiex_exec_next_cmd(struct mwifiex_adapter *adapter);\ndrivers/net/wireless/marvell/mwifiex/main.h:1101:int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter);\ndrivers/net/wireless/marvell/mwifiex/main.h-1102-void mwifiex_process_assoc_resp(struct mwifiex_adapter *adapter);\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=31=static void\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:32:mwifiex_process_cmdresp_error(struct mwifiex_private *priv,\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-33-\t\t\t      struct host_cmd_ds_command *resp)\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c=1212=int mwifiex_process_sta_cmdresp(struct mwifiex_private *priv, u16 cmdresp_no,\n--\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1220-\tif (resp-\u003eresult != HostCmd_RESULT_OK) {\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c:1221:\t\tmwifiex_process_cmdresp_error(priv, resp);\ndrivers/net/wireless/marvell/mwifiex/sta_cmdresp.c-1222-\t\treturn -1;\n"
}

							input: 27428
							output: 34
							thoughts: 585

**Fuzzing Target Identification: `mwifiex_ret_wmm_get_status`**

Okay, so I'm looking at `mwifiex_ret_wmm_get_status`. This function gets executed when the driver processes a WMM_GET_STATUS response from the firmware. Because this driver, `mwifiex`, uses a USB bus interface (`MWIFIEX_USB`), it's accessible within the standard virtualized environments I'm using, thanks to USB device emulation using tools like raw-gadget, dummy_hcd, or usb-fuzzer. So, the question is, is this a good candidate for fuzzing?

Let's break it down based on the established criteria. Section 3 says:

*   **Reachable Drivers and Protocols:** Specifically, drivers reachable via virtual buses, which this *absolutely* is, given its USB interface. Check.
*   **Runtime Assertions and Defensive Checks:** We need to look at any bounds checks or defensive validation, especially for device-supplied TLVs. This function definitely handles data from the firmware, so there's likely some validation happening here. Check.

Therefore, WorthFuzzing = True.

Now, let's identify the specific fuzzing targets and their context. The function itself, `mwifiex_ret_wmm_get_status`, is the primary focus. Additionally, its caller, `mwifiex_process_sta_cmdresp`, is also relevant. We know that `mwifiex_ret_wmm_get_status` is a non-static C function residing in `drivers/net/wireless/marvell/mwifiex/wmm.c`. I need to confirm that this function is actually a symbol that can be reached, and yes, it is defined in the kernel as: `int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv, const struct host_cmd_ds_command *resp)`. Excellent. And `mwifiex_process_sta_cmdresp` is, as expected, in `sta_cmdresp.c`.

Next, the necessary configurations. We need to make sure we have the right kernel modules enabled to make this function reachable:

*   `MWIFIEX`
*   `MWIFIEX_USB`
*   `CFG80211`
*   `USB`
*   `WLAN_VENDOR_MARVELL`

Let's verify `WLAN_VENDOR_MARVELL`'s dependencies: I can see in `drivers/net/wireless/marvell/Kconfig` that `WLAN_VENDOR_MARVELL` includes `mwifiex/Kconfig`, and within `drivers/net/wireless/marvell/mwifiex/Kconfig`: `MWIFIEX` depends on `CFG80211`, and `MWIFIEX_USB` depends on `MWIFIEX && USB`. Alright, that looks sound. It's always good to double-check in `drivers/net/wireless/Kconfig` to ensure nothing else is needed, but based on what I see here, we should be good to go.

{
  "Expression": "WLAN_VENDOR_MARVELL",
  "PathPrefix": "drivers/net/wireless/"
}

{
  "Output": "drivers/net/wireless/Makefile=11=obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/\ndrivers/net/wireless/Makefile:12:obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/\ndrivers/net/wireless/Makefile-13-obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/\n--\ndrivers/net/wireless/marvell/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/wireless/marvell/Kconfig:2:config WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-3-\tbool \"Marvell devices\"\n--\ndrivers/net/wireless/marvell/Kconfig-12-\ndrivers/net/wireless/marvell/Kconfig:13:if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\n--\ndrivers/net/wireless/marvell/Kconfig=19=config MWL8K\n--\ndrivers/net/wireless/marvell/Kconfig-27-\ndrivers/net/wireless/marvell/Kconfig:28:endif # WLAN_VENDOR_MARVELL\n"
}

							input: 29028
							output: 32
							thoughts: 25

Here's a summary of my thought process, as if I were thinking it:

**Diving into the Wireless Kernel Configuration**

Okay, so we need to zero in on the Marvell WLAN driver configuration. My first step is to navigate directly to the heart of the matter: `drivers/net/wireless/Kconfig`. This is where all the wireless device configurations are housed. Specifically, I'm thinking about the section related to `WLAN_VENDOR_MARVELL`. That variable is the key. I need to understand the dependencies, default values, and any other relevant configurations related to this specific Marvell driver. This file will tell me how the Marvell driver is enabled, disabled, and what features are controlled. I expect to find dependencies on other configuration options and hopefully, some helpful comments to guide my understanding. Let's see what we can find.

{
  "Expression": "WLAN_VENDOR_MARVELL",
  "PathPrefix": "drivers/net/"
}

{
  "Output": "drivers/net/wireless/Makefile=11=obj-$(CONFIG_WLAN_VENDOR_INTERSIL) += intersil/\ndrivers/net/wireless/Makefile:12:obj-$(CONFIG_WLAN_VENDOR_MARVELL) += marvell/\ndrivers/net/wireless/Makefile-13-obj-$(CONFIG_WLAN_VENDOR_MEDIATEK) += mediatek/\n--\ndrivers/net/wireless/marvell/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/wireless/marvell/Kconfig:2:config WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-3-\tbool \"Marvell devices\"\n--\ndrivers/net/wireless/marvell/Kconfig-12-\ndrivers/net/wireless/marvell/Kconfig:13:if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\n--\ndrivers/net/wireless/marvell/Kconfig=19=config MWL8K\n--\ndrivers/net/wireless/marvell/Kconfig-27-\ndrivers/net/wireless/marvell/Kconfig:28:endif # WLAN_VENDOR_MARVELL\n"
}

							input: 29564
							output: 30
							thoughts: 24

Here's a summary of my thought process, as requested:

**Investigating WLAN Dependencies**

Okay, so I need to figure out the requirements for something related to WLAN. My first step is to dive into the kernel's Kconfig files. Specifically, I'll navigate to `drivers/net/wireless/Kconfig`. This is where the configuration options for wireless network devices are defined, so it's a logical starting point. I need to understand if WLAN itself, as a foundational concept, has any hard dependencies that I should be aware of. This should tell me what I need to consider for this process.

{
  "Expression": "source.*marvell",
  "PathPrefix": "drivers/net/wireless/"
}

{
  "Output": "drivers/net/wireless/Kconfig=26=source \"drivers/net/wireless/intersil/Kconfig\"\ndrivers/net/wireless/Kconfig:27:source \"drivers/net/wireless/marvell/Kconfig\"\ndrivers/net/wireless/Kconfig-28-source \"drivers/net/wireless/mediatek/Kconfig\"\n--\ndrivers/net/wireless/marvell/Kconfig=13=if WLAN_VENDOR_MARVELL\ndrivers/net/wireless/marvell/Kconfig-14-\ndrivers/net/wireless/marvell/Kconfig:15:source \"drivers/net/wireless/marvell/libertas/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:16:source \"drivers/net/wireless/marvell/libertas_tf/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig:17:source \"drivers/net/wireless/marvell/mwifiex/Kconfig\"\ndrivers/net/wireless/marvell/Kconfig-18-\n"
}

							input: 30000
							output: 34
							thoughts: 22

Here's my summary, as if I were thinking these thoughts:

**Examining the Wireless Kconfig**

Alright, time to dig into the `drivers/net/wireless/Kconfig` file. I'm focusing on lines 1 through 35, which usually contains the top-level configuration options for the entire wireless subsystem or major architectural decisions. I anticipate seeing things like:

*   The main "Wireless Networking" entry itself, the gateway to everything else wireless.
*   Potentially, whether certain major wireless protocols are enabled by default or configurable.
*   Options to choose between different wireless stacks, if that level of abstraction exists in this kernel version.
*   Defines for broad wireless functionality, like support for certain frequency bands or device types.
*   Basic help text explaining the purpose of the wireless subsystem and maybe a few key configurations.

Given the line range, I expect this section to lay the groundwork and set the overall direction for the rest of the configuration. Let's see what the designers prioritized as important to expose to end users and developers at the initial level. I'll need to assess the conditional logic and dependencies to understand the branching.

{
  "File": "drivers/net/wireless/Kconfig",
  "FirstLine": 1,
  "LineCount": 35
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t#\n   3:\t# Wireless LAN device configuration\n   4:\t#\n   5:\t\n   6:\tmenuconfig WLAN\n   7:\t\tbool \"Wireless LAN\"\n   8:\t\tdepends on !S390\n   9:\t\tdepends on NET\n  10:\t\tselect WIRELESS\n  11:\t\tdefault y\n  12:\t\thelp\n  13:\t\t  This section contains all the pre 802.11 and 802.11 wireless\n  14:\t\t  device drivers. For a complete list of drivers and documentation\n  15:\t\t  on them refer to the wireless wiki:\n  16:\t\n  17:\t\t  https://wireless.wiki.kernel.org/en/users/Drivers\n  18:\t\n  19:\tif WLAN\n  20:\t\n  21:\tsource \"drivers/net/wireless/admtek/Kconfig\"\n  22:\tsource \"drivers/net/wireless/ath/Kconfig\"\n  23:\tsource \"drivers/net/wireless/atmel/Kconfig\"\n  24:\tsource \"drivers/net/wireless/broadcom/Kconfig\"\n  25:\tsource \"drivers/net/wireless/intel/Kconfig\"\n  26:\tsource \"drivers/net/wireless/intersil/Kconfig\"\n  27:\tsource \"drivers/net/wireless/marvell/Kconfig\"\n  28:\tsource \"drivers/net/wireless/mediatek/Kconfig\"\n  29:\tsource \"drivers/net/wireless/microchip/Kconfig\"\n  30:\tsource \"drivers/net/wireless/morsemicro/Kconfig\"\n  31:\tsource \"drivers/net/wireless/nxp/Kconfig\"\n  32:\tsource \"drivers/net/wireless/purelifi/Kconfig\"\n  33:\tsource \"drivers/net/wireless/ralink/Kconfig\"\n  34:\tsource \"drivers/net/wireless/realtek/Kconfig\"\n  35:\tsource \"drivers/net/wireless/rsi/Kconfig\"\n"
}

							input: 30831
							output: 173
							thoughts: 301

**My Analysis of This Vulnerability**

Okay, so based on this information, I've got a handle on what's going on. This looks like a solid finding. Essentially, there's a bounds check vulnerability in the `mwifiex` driver, specifically within the `mwifiex_ret_wmm_get_status()` function. The good news is, they've identified that the patch introduces a bounds check on `tlv_wmm_qstatus->queue_index` against `IEEE80211_NUM_ACS`, meaning it prevents out-of-bounds array indexing in `priv->wmm.ac_status`, which I like to see.

Now, the really interesting part is the potential for fuzzing. The fact that the `mwifiex` driver is accessible via `MWIFIEX_USB` (USB gadget/vHCI emulation) is key. That means we can send firmware command responses, making this fuzzable. That also makes this much more exciting.

To be clear on what needs to be enabled for this, here are the configurations that are relevant, `MWIFIEX`, `MWIFIEX_USB`, `WLAN`, `WLAN_VENDOR_MARVELL`, `CFG80211`, and `USB`. Those are the ones to focus on.

The main functions I need to keep an eye on are `mwifiex_ret_wmm_get_status` and `mwifiex_process_sta_cmdresp`.

Finally, based on this information, it's definitely worth fuzzing and, I'm confident in saying the information is all there, so I am going to call `set-results`.

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "WLAN",
    "WLAN_VENDOR_MARVELL",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "mwifiex_ret_wmm_get_status",
    "mwifiex_process_sta_cmdresp"
  ],
  "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "WLAN",
    "WLAN_VENDOR_MARVELL",
    "CFG80211",
    "USB"
  ],
  "FocusSymbols": [
    "mwifiex_ret_wmm_get_status",
    "mwifiex_process_sta_cmdresp"
  ],
  "Reasoning": "The patch adds a bounds check in mwifiex_ret_wmm_get_status() to validate queue_index before indexing into priv-\u003ewmm.ac_status. The mwifiex driver supports USB-based devices (CONFIG_MWIFIEX_USB), making it reachable and testable in virtualized fuzzing environments via USB emulation.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

{
  "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. 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.

Target architecture: amd64

For your convenience, here is the diff of the changes:
commit 73b4040799d19dc62797c1bb9066af8d27359825
Author: syz-cluster <triage@syzkaller.com>
Date:   Mon Sep 7 08:32:06 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 841505e83c7fd..febea68487e84 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -943,6 +943,8 @@ int mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,
 				    tlv_wmm_qstatus->flow_required,
 				    tlv_wmm_qstatus->disabled);
 
+			if (tlv_wmm_qstatus->queue_index >= IEEE80211_NUM_ACS)
+				break;
 			ac_status = &priv->wmm.ac_status[tlv_wmm_qstatus->
 							 queue_index];
 			ac_status->disabled = tlv_wmm_qstatus->disabled;

							input: 2150
							output: 45
							thoughts: 46

Here's my analysis of the provided snippet, as if it were my thought process:

**Diving into the Code: WMM Context**

Okay, time to get my hands dirty. I'm going to start by analyzing this patch, but first, I need a good point of reference. Let's start with `drivers/net/wireless/marvell/mwifiex/wmm.c` around line 943. This is where the core of the WMM implementation should be, so it's a logical starting point. The line number is a good starting place, and using that in conjunction with a source code browser or debugger will quickly give me the context I need. This way I can see exactly how the surrounding code interacts with the changed area.

{
  "File": "drivers/net/wireless/marvell/mwifiex/wmm.c",
  "FirstLine": 920,
  "LineCount": 50
}

{
  "Contents": " 920:\t\tstruct ieee_types_wmm_parameter *wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status *ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t    \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t    resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data *) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status *)\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n 940:\t\t\t\t\t    \"info: CMD_RESP: WMM_GET_STATUS:\\t\"\n 941:\t\t\t\t\t    \"QSTATUS TLV: %d, %d, %d\\n\",\n 942:\t\t\t\t\t    tlv_wmm_qstatus-\u003equeue_index,\n 943:\t\t\t\t\t    tlv_wmm_qstatus-\u003eflow_required,\n 944:\t\t\t\t\t    tlv_wmm_qstatus-\u003edisabled);\n 945:\t\n 946:\t\t\t\tif (tlv_wmm_qstatus-\u003equeue_index \u003e= IEEE80211_NUM_ACS)\n 947:\t\t\t\t\tbreak;\n 948:\t\t\t\tac_status = \u0026priv-\u003ewmm.ac_status[tlv_wmm_qstatus-\u003e\n 949:\t\t\t\t\t\t\t\t queue_index];\n 950:\t\t\t\tac_status-\u003edisabled = tlv_wmm_qstatus-\u003edisabled;\n 951:\t\t\t\tac_status-\u003eflow_required =\n 952:\t\t\t\t\t\t\ttlv_wmm_qstatus-\u003eflow_required;\n 953:\t\t\t\tac_status-\u003eflow_created = tlv_wmm_qstatus-\u003eflow_created;\n 954:\t\t\t\tbreak;\n 955:\t\n 956:\t\t\tcase WLAN_EID_VENDOR_SPECIFIC:\n 957:\t\t\t\t/*\n 958:\t\t\t\t * Point the regular IEEE IE 2 bytes into the Marvell IE\n 959:\t\t\t\t *   and setup the IEEE IE type and length byte fields\n 960:\t\t\t\t */\n 961:\t\n 962:\t\t\t\twmm_param_ie =\n 963:\t\t\t\t\t(struct ieee_types_wmm_parameter *) (curr +\n 964:\t\t\t\t\t\t\t\t\t    2);\n 965:\t\t\t\twmm_param_ie-\u003evend_hdr.len = (u8) tlv_len;\n 966:\t\t\t\twmm_param_ie-\u003evend_hdr.element_id =\n 967:\t\t\t\t\t\t\tWLAN_EID_VENDOR_SPECIFIC;\n 968:\t\n 969:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n"
}

							input: 3312
							output: 45
							thoughts: 36

Okay, let's dive into this code.

**Analyzing the Function and the Bug Fix**

Right, so I need to understand what this function, specifically `mwifiex_ret_wmm_get_status`, is doing and, crucially, what problem it's addressing. The bug fix documentation should give me a good starting point, but I always prefer to get a feel for the code itself first. Understanding the *context* of the fix is vital. I'll need to look at how this function is used elsewhere, and which variables are passed to it. Let's start by digging into `mwifiex_ret_wmm_get_status` and see what it has to offer.

{
  "File": "drivers/net/wireless/marvell/mwifiex/wmm.c",
  "FirstLine": 900,
  "LineCount": 40
}

{
  "Contents": " 900:\t * This function processes the get WMM status command response from firmware.\n 901:\t *\n 902:\t * The response may contain multiple TLVs -\n 903:\t *      - AC Queue status TLVs\n 904:\t *      - Current WMM Parameter IE TLV\n 905:\t *      - Admission Control action frame TLVs\n 906:\t *\n 907:\t * This function parses the TLVs and then calls further specific functions\n 908:\t * to process any changes in the queue prioritize or state.\n 909:\t */\n 910:\tint mwifiex_ret_wmm_get_status(struct mwifiex_private *priv,\n 911:\t\t\t\t       const struct host_cmd_ds_command *resp)\n 912:\t{\n 913:\t\tu8 *curr = (u8 *) \u0026resp-\u003eparams.get_wmm_status;\n 914:\t\tuint16_t resp_len = le16_to_cpu(resp-\u003esize), tlv_len;\n 915:\t\tint mask = IEEE80211_WMM_IE_AP_QOSINFO_PARAM_SET_CNT_MASK;\n 916:\t\tbool valid = true;\n 917:\t\n 918:\t\tstruct mwifiex_ie_types_data *tlv_hdr;\n 919:\t\tstruct mwifiex_ie_types_wmm_queue_status *tlv_wmm_qstatus;\n 920:\t\tstruct ieee_types_wmm_parameter *wmm_param_ie = NULL;\n 921:\t\tstruct mwifiex_wmm_ac_status *ac_status;\n 922:\t\n 923:\t\tmwifiex_dbg(priv-\u003eadapter, INFO,\n 924:\t\t\t    \"info: WMM: WMM_GET_STATUS cmdresp received: %d\\n\",\n 925:\t\t\t    resp_len);\n 926:\t\n 927:\t\twhile ((resp_len \u003e= sizeof(tlv_hdr-\u003eheader)) \u0026\u0026 valid) {\n 928:\t\t\ttlv_hdr = (struct mwifiex_ie_types_data *) curr;\n 929:\t\t\ttlv_len = le16_to_cpu(tlv_hdr-\u003eheader.len);\n 930:\t\n 931:\t\t\tif (resp_len \u003c tlv_len + sizeof(tlv_hdr-\u003eheader))\n 932:\t\t\t\tbreak;\n 933:\t\n 934:\t\t\tswitch (le16_to_cpu(tlv_hdr-\u003eheader.type)) {\n 935:\t\t\tcase TLV_TYPE_WMMQSTATUS:\n 936:\t\t\t\ttlv_wmm_qstatus =\n 937:\t\t\t\t\t(struct mwifiex_ie_types_wmm_queue_status *)\n 938:\t\t\t\t\ttlv_hdr;\n 939:\t\t\t\tmwifiex_dbg(priv-\u003eadapter, CMD,\n"
}

							input: 4303
							output: 158
							thoughts: 649

**My Analysis of the Patch**

Okay, so I'm looking at this patch and immediately, I recognize it as a pretty straightforward bounds check. It's adding a safeguard against an out-of-bounds write. Specifically, it's checking if `tlv_wmm_qstatus->queue_index` is within the valid range for the `priv->wmm.ac_status` array before accessing it. The array is sized by `IEEE80211_NUM_ACS`, which is 4. Without this, we'd have a classic array indexing vulnerability – a potential out-of-bounds write. KASAN would definitely catch that, which is good.

My immediate thought is, is there any uninitialized memory aspect I need to look into? Let's see... the `tlv_wmm_qstatus` data comes from a firmware command response, so it's initialized by the firmware. The `queue_index` itself is *then* checked, so if it's out of bounds, the code just breaks, and doesn't write to the array. The `ac_status` array fields are populated from `tlv_wmm_qstatus`. Seems like everything's initialized and there's no way to read uninitialized memory, leak info, or introduce an uninitialized variable. This is purely a bounds check for the write.

Now, let's apply the rule: "THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN, LOCKDEP, OR OTHER STANDARD BUG DETECTORS." This is all KASAN, all day long. And, "NeedsKMSAN=false IF...The code changes primarily risk out-of-bounds access...these are already caught by KASAN...". The patch doesn't introduce any risk of uninitialized memory usage or info-leaks, and all structures are fully initialized. It's a clean, defensive fix.

So, yeah, given that, `NeedsKMSAN` should absolutely be `false`. I'm going to double-check everything one last time, just to be absolutely sure, and then I'll get that `set-results` call ready.

{
  "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch adds an array bounds check on `tlv_wmm_qstatus-\u003equeue_index` against `IEEE80211_NUM_ACS` before accessing `priv-\u003ewmm.ac_status[...]` in `mwifiex_ret_wmm_get_status()`. This addresses an out-of-bounds array access / buffer overflow issue, which is properly detected by KASAN. The patch does not introduce, alter, or expose uninitialized memory reads, uninitialized structure copies, or kernel-to-user info-leaks. Therefore, a dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

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

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