| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/09/07 14:47 | flow | patch-triage |
1mArgs:null Results: {
"EnableConfigs": [
"MAC80211",
"CFG80211"
],
"FocusSymbols": [
"ieee80211_tx_h_check_offchannel",
"invoke_tx_handlers_late",
"ieee80211_tx_h_check_assoc",
"ieee80211_8023_xmit",
"ieee80211_subif_start_xmit",
"ieee80211_subif_start_xmit_8023"
],
"KMSANReasoning": "The patch refactors off-channel frame filtering in mac80211 by moving the software scanning off-channel drop check from early TX handling (ieee80211_tx_h_check_assoc and ieee80211_8023_xmit) into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked in invoke_tx_handlers_late().\n\nThis change only affects internal control flow and packet drop decisions during TX processing on existing, initialized skb headers and state bitmaps. It does not introduce or modify any data allocations, structure copying to user space, uninitialized variable accesses, or buffer boundary calculations. Standard KASAN fuzzing is sufficient to cover any packet handling or lifecycle issues, and a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false,
"Reasoning": "The patch refactors the mac80211 TX path by consolidating off-channel frame dropping during software scanning into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked via invoke_tx_handlers_late(), while removing redundant checks from ieee80211_tx_h_check_assoc() and ieee80211_8023_xmit(). This modifies reachable network transmission logic accessible via standard virtualized wireless interfaces (such as mac80211_hwsim), making it suitable for fuzzing.",
"WorthFuzzing": true
} |
| 1/1 | 2026/09/07 14:47 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit 6b7cd5bcc482deb802b89227fc840fa9b6981b02\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Mon Sep 7 14:47:41 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/net/mac80211/tx.c b/net/mac80211/tx.c\nindex 91b14112e24f0..08a39272f26a0 100644\n--- a/net/mac80211/tx.c\n+++ b/net/mac80211/tx.c\n@@ -269,7 +269,6 @@ ieee80211_tx_h_dynamic_ps(struct ieee80211_tx_data *tx)\n static ieee80211_tx_result debug_noinline\n ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)\n {\n-\n \tstruct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-\u003eskb-\u003edata;\n \tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-\u003eskb);\n \tbool assoc = false;\n@@ -277,20 +276,6 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)\n \tif (unlikely(info-\u003eflags \u0026 IEEE80211_TX_CTL_INJECTED))\n \t\treturn TX_CONTINUE;\n \n-\tif (unlikely(test_bit(SCAN_SW_SCANNING, \u0026tx-\u003elocal-\u003escanning)) \u0026\u0026\n-\t test_bit(SDATA_STATE_OFFCHANNEL, \u0026tx-\u003esdata-\u003estate) \u0026\u0026\n-\t !ieee80211_is_probe_req(hdr-\u003eframe_control) \u0026\u0026\n-\t !ieee80211_is_any_nullfunc(hdr-\u003eframe_control))\n-\t\t/*\n-\t\t * When software scanning only nullfunc frames (to notify\n-\t\t * the sleep state to the AP) and probe requests (for the\n-\t\t * active scan) are allowed, all other frames should not be\n-\t\t * sent and we should not get here, but if we do\n-\t\t * nonetheless, drop them to avoid sending them\n-\t\t * off-channel. See __ieee80211_start_scan() for more.\n-\t\t */\n-\t\treturn TX_DROP;\n-\n \tif (tx-\u003esdata-\u003evif.type == NL80211_IFTYPE_OCB)\n \t\treturn TX_CONTINUE;\n \n@@ -805,6 +790,33 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)\n \treturn TX_CONTINUE;\n }\n \n+static ieee80211_tx_result debug_noinline\n+ieee80211_tx_h_check_offchannel(struct ieee80211_tx_data *tx)\n+{\n+\tstruct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx-\u003eskb-\u003edata;\n+\tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-\u003eskb);\n+\n+\tif (unlikely(info-\u003eflags \u0026 IEEE80211_TX_CTL_INJECTED))\n+\t\treturn TX_CONTINUE;\n+\n+\tif (unlikely(test_bit(SCAN_SW_SCANNING, \u0026tx-\u003elocal-\u003escanning)) \u0026\u0026\n+\t test_bit(SDATA_STATE_OFFCHANNEL, \u0026tx-\u003esdata-\u003estate) \u0026\u0026\n+\t !ieee80211_is_probe_req(hdr-\u003eframe_control) \u0026\u0026\n+\t !ieee80211_is_any_nullfunc(hdr-\u003eframe_control)) {\n+\t\t/*\n+\t\t * When software scanning only nullfunc frames (to notify\n+\t\t * the sleep state to the AP) and probe requests (for the\n+\t\t * active scan) are allowed, all other frames should not be\n+\t\t * sent and we should not get here, but if we do\n+\t\t * nonetheless, drop them to avoid sending them\n+\t\t * off-channel. See __ieee80211_start_scan() for more.\n+\t\t */\n+\t\treturn TX_DROP;\n+\t}\n+\n+\treturn TX_CONTINUE;\n+}\n+\n static __le16 ieee80211_tx_next_seq(struct sta_info *sta, int tid)\n {\n \tu16 *seq = \u0026sta-\u003etid_seq[tid];\n@@ -1864,6 +1876,7 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)\n \t\tgoto txh_done;\n \t}\n \n+\tCALL_TXH(ieee80211_tx_h_check_offchannel);\n \tCALL_TXH(ieee80211_tx_h_michael_mic_add);\n \tCALL_TXH(ieee80211_tx_h_sequence);\n \tCALL_TXH(ieee80211_tx_h_fragment);\n@@ -4686,10 +4699,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,\n \tqueue = ieee80211_select_queue(sdata, sta, skb);\n \tskb_set_queue_mapping(skb, queue);\n \n-\tif (unlikely(test_bit(SCAN_SW_SCANNING, \u0026local-\u003escanning)) \u0026\u0026\n-\t test_bit(SDATA_STATE_OFFCHANNEL, \u0026sdata-\u003estate))\n-\t\tgoto out_free;\n-\n \tskb = skb_share_check(skb, GFP_ATOMIC);\n \tif (unlikely(!skb))\n \t\treturn;\n@@ -4756,11 +4765,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,\n \tieee80211_tpt_led_trig_tx(local, len);\n \n \tieee80211_tx_8023(sdata, skb, sta, false);\n-\n-\treturn;\n-\n-out_free:\n-\tkfree_skb(skb);\n }\n \n static bool ieee80211_check_mcast_offload(struct ieee80211_sub_if_data *sdata,\n"
} |
| 2/1 | 2026/09/07 14:47 | agent | patch-evaluator |
1mModel:core Args: null Results: {
"EnableConfigs": [
"MAC80211",
"CFG80211"
],
"FocusSymbols": [
"ieee80211_tx_h_check_offchannel",
"invoke_tx_handlers_late",
"ieee80211_tx_h_check_assoc",
"ieee80211_8023_xmit",
"ieee80211_subif_start_xmit",
"ieee80211_subif_start_xmit_8023"
],
"Reasoning": "The patch refactors the mac80211 TX path by consolidating off-channel frame dropping during software scanning into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked via invoke_tx_handlers_late(), while removing redundant checks from ieee80211_tx_h_check_assoc() and ieee80211_8023_xmit(). This modifies reachable network transmission logic accessible via standard virtualized wireless interfaces (such as mac80211_hwsim), making it suitable for fuzzing.",
"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 6b7cd5bcc482deb802b89227fc840fa9b6981b02
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 7 14:47:41 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91b14112e24f0..08a39272f26a0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -269,7 +269,6 @@ ieee80211_tx_h_dynamic_ps(struct ieee80211_tx_data *tx)
static ieee80211_tx_result debug_noinline
ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
{
-
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
bool assoc = false;
@@ -277,20 +276,6 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED))
return TX_CONTINUE;
- if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) &&
- test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) &&
- !ieee80211_is_probe_req(hdr->frame_control) &&
- !ieee80211_is_any_nullfunc(hdr->frame_control))
- /*
- * When software scanning only nullfunc frames (to notify
- * the sleep state to the AP) and probe requests (for the
- * active scan) are allowed, all other frames should not be
- * sent and we should not get here, but if we do
- * nonetheless, drop them to avoid sending them
- * off-channel. See __ieee80211_start_scan() for more.
- */
- return TX_DROP;
-
if (tx->sdata->vif.type == NL80211_IFTYPE_OCB)
return TX_CONTINUE;
@@ -805,6 +790,33 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
return TX_CONTINUE;
}
+static ieee80211_tx_result debug_noinline
+ieee80211_tx_h_check_offchannel(struct ieee80211_tx_data *tx)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
+
+ if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED))
+ return TX_CONTINUE;
+
+ if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) &&
+ test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) &&
+ !ieee80211_is_probe_req(hdr->frame_control) &&
+ !ieee80211_is_any_nullfunc(hdr->frame_control)) {
+ /*
+ * When software scanning only nullfunc frames (to notify
+ * the sleep state to the AP) and probe requests (for the
+ * active scan) are allowed, all other frames should not be
+ * sent and we should not get here, but if we do
+ * nonetheless, drop them to avoid sending them
+ * off-channel. See __ieee80211_start_scan() for more.
+ */
+ return TX_DROP;
+ }
+
+ return TX_CONTINUE;
+}
+
static __le16 ieee80211_tx_next_seq(struct sta_info *sta, int tid)
{
u16 *seq = &sta->tid_seq[tid];
@@ -1864,6 +1876,7 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
goto txh_done;
}
+ CALL_TXH(ieee80211_tx_h_check_offchannel);
CALL_TXH(ieee80211_tx_h_michael_mic_add);
CALL_TXH(ieee80211_tx_h_sequence);
CALL_TXH(ieee80211_tx_h_fragment);
@@ -4686,10 +4699,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
queue = ieee80211_select_queue(sdata, sta, skb);
skb_set_queue_mapping(skb, queue);
- if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)) &&
- test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state))
- goto out_free;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return;
@@ -4756,11 +4765,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
ieee80211_tpt_led_trig_tx(local, len);
ieee80211_tx_8023(sdata, skb, sta, false);
-
- return;
-
-out_free:
- kfree_skb(skb);
}
static bool ieee80211_check_mcast_offload(struct ieee80211_sub_if_data *sdata,
|
| 3/2 | 2026/09/07 14:47 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 4317 output: 36 thoughts: 337 Thoughts: **Analyzing the Proposed Patch and its Implications** Okay, let's break this down. My initial impression is that we're dealing with a patch related to off-channel operation within the `net/mac80211` subsystem, specifically concerning transmit behavior. The diff points squarely at `net/mac80211/tx.c`, which is a key area for performance and reliability in any 802.11 implementation. The first change in `ieee80211_tx_h_check_assoc()` jumps out. Removing the off-channel check during scanning is interesting. It implies a shift in how the driver handles off-channel activity when a station is actively scanning for networks. Then, the introduction of `ieee80211_tx_h_check_offchannel()` and the late invocation within `invoke_tx_handlers_late()` is critical. This signals a new tx handler specifically designed to handle off-channel scenarios and it suggests that the off-channel handling logic is now being deferred to the later stages of the transmit process. This may impact various aspects, such as throughput, latency, or even frame ordering. It would be important to study the function implementation in detail. Additionally, the removal of the specific check within `ieee80211_8023_xmit()` is worth noting. This `goto out_free` statement was likely a fast-path optimization or a safeguard to prevent transmission on off-channel. Its removal, especially in combination with the new handler, indicates a potentially more nuanced and flexible approach to off-channel transmission. It also suggests that this particular check was no longer needed because the new `ieee80211_tx_h_check_offchannel()` handler has replaced it or is taking care of the work done by the earlier check. The next question: how vulnerable is this code to fuzzing? Knowing that `mac80211` is heavily exercised by syzkaller through `mac80211_hwsim`, nl80211, and standard socket transmissions, I'm already inclined to believe that this change will be exposed to significant testing pressure. The fact that these interfaces are reachable means any bugs introduced here have a good chance of being found relatively quickly. I need to keep this in mind as I start to investigate the implementation details more thoroughly. |
| 4/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "CONFIG_MAC80211",
"PathPrefix": "net/mac80211"
}Results: {
"Output": "net/mac80211/Makefile-1-# SPDX-License-Identifier: GPL-2.0\nnet/mac80211/Makefile:2:obj-$(CONFIG_MAC80211) += mac80211.o\nnet/mac80211/Makefile-3-\n--\nnet/mac80211/Makefile=5=mac80211-y := \\\n--\nnet/mac80211/Makefile-39-\nnet/mac80211/Makefile:40:mac80211-$(CONFIG_MAC80211_LEDS) += led.o\nnet/mac80211/Makefile:41:mac80211-$(CONFIG_MAC80211_DEBUGFS) += \\\nnet/mac80211/Makefile-42-\tdebugfs.o \\\n--\nnet/mac80211/Makefile-46-\nnet/mac80211/Makefile:47:mac80211-$(CONFIG_MAC80211_MESH) += \\\nnet/mac80211/Makefile-48-\tmesh.o \\\n--\nnet/mac80211/Makefile=59=rc80211_minstrel-y := \\\n--\nnet/mac80211/Makefile-61-\nnet/mac80211/Makefile:62:rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \\\nnet/mac80211/Makefile-63-\trc80211_minstrel_ht_debugfs.o\nnet/mac80211/Makefile-64-\nnet/mac80211/Makefile:65:mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)\nnet/mac80211/Makefile-66-\n--\nnet/mac80211/cfg.c=613=static int ieee80211_add_key(struct wiphy *wiphy, struct wireless_dev *wdev,\n--\nnet/mac80211/cfg.c-710-\tcase NL80211_IFTYPE_MESH_POINT:\nnet/mac80211/cfg.c:711:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-712-\t\tif (sdata-\u003eu.mesh.security != IEEE80211_MESH_SEC_NONE)\n--\nnet/mac80211/cfg.c=2190=static void sta_apply_mesh_params(struct ieee80211_local *local,\n--\nnet/mac80211/cfg.c-2193-{\nnet/mac80211/cfg.c:2194:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-2195-\tstruct ieee80211_sub_if_data *sdata = sta-\u003esdata;\n--\nnet/mac80211/cfg.c=2787=static int ieee80211_change_station(struct wiphy *wiphy,\n--\nnet/mac80211/cfg.c-2893-\nnet/mac80211/cfg.c:2894:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-2895-static int ieee80211_add_mpath(struct wiphy *wiphy, struct net_device *dev,\n--\nnet/mac80211/cfg.c=4428=static int ieee80211_set_after_csa_beacon(struct ieee80211_link_data *link_data,\n--\nnet/mac80211/cfg.c-4451-\t\tbreak;\nnet/mac80211/cfg.c:4452:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-4453-\tcase NL80211_IFTYPE_MESH_POINT:\n--\nnet/mac80211/cfg.c=4563=static int ieee80211_set_csa_beacon(struct ieee80211_link_data *link_data,\n--\nnet/mac80211/cfg.c-4654-\t\tbreak;\nnet/mac80211/cfg.c:4655:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-4656-\tcase NL80211_IFTYPE_MESH_POINT: {\n--\nnet/mac80211/cfg.c=5991=const struct cfg80211_ops mac80211_config_ops = {\n--\nnet/mac80211/cfg.c-6011-\t.dump_survey = ieee80211_dump_survey,\nnet/mac80211/cfg.c:6012:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/cfg.c-6013-\t.add_mpath = ieee80211_add_mpath,\n--\nnet/mac80211/debug.h-10-\nnet/mac80211/debug.h:11:#ifdef CONFIG_MAC80211_OCB_DEBUG\nnet/mac80211/debug.h-12-#define MAC80211_OCB_DEBUG 1\n--\nnet/mac80211/debug.h-16-\nnet/mac80211/debug.h:17:#ifdef CONFIG_MAC80211_IBSS_DEBUG\nnet/mac80211/debug.h-18-#define MAC80211_IBSS_DEBUG 1\n--\nnet/mac80211/debug.h-22-\nnet/mac80211/debug.h:23:#ifdef CONFIG_MAC80211_PS_DEBUG\nnet/mac80211/debug.h-24-#define MAC80211_PS_DEBUG 1\n--\nnet/mac80211/debug.h-28-\nnet/mac80211/debug.h:29:#ifdef CONFIG_MAC80211_HT_DEBUG\nnet/mac80211/debug.h-30-#define MAC80211_HT_DEBUG 1\n--\nnet/mac80211/debug.h-34-\nnet/mac80211/debug.h:35:#ifdef CONFIG_MAC80211_MPL_DEBUG\nnet/mac80211/debug.h-36-#define MAC80211_MPL_DEBUG 1\n--\nnet/mac80211/debug.h-40-\nnet/mac80211/debug.h:41:#ifdef CONFIG_MAC80211_MPATH_DEBUG\nnet/mac80211/debug.h-42-#define MAC80211_MPATH_DEBUG 1\n--\nnet/mac80211/debug.h-46-\nnet/mac80211/debug.h:47:#ifdef CONFIG_MAC80211_MHWMP_DEBUG\nnet/mac80211/debug.h-48-#define MAC80211_MHWMP_DEBUG 1\n--\nnet/mac80211/debug.h-52-\nnet/mac80211/debug.h:53:#ifdef CONFIG_MAC80211_MESH_SYNC_DEBUG\nnet/mac80211/debug.h-54-#define MAC80211_MESH_SYNC_DEBUG 1\n--\nnet/mac80211/debug.h-58-\nnet/mac80211/debug.h:59:#ifdef CONFIG_MAC80211_MESH_CSA_DEBUG\nnet/mac80211/debug.h-60-#define MAC80211_MESH_CSA_DEBUG 1\n--\nnet/mac80211/debug.h-64-\nnet/mac80211/debug.h:65:#ifdef CONFIG_MAC80211_MESH_PS_DEBUG\nnet/mac80211/debug.h-66-#define MAC80211_MESH_PS_DEBUG 1\n--\nnet/mac80211/debug.h-70-\nnet/mac80211/debug.h:71:#ifdef CONFIG_MAC80211_TDLS_DEBUG\nnet/mac80211/debug.h-72-#define MAC80211_TDLS_DEBUG 1\n--\nnet/mac80211/debug.h-76-\nnet/mac80211/debug.h:77:#ifdef CONFIG_MAC80211_STA_DEBUG\nnet/mac80211/debug.h-78-#define MAC80211_STA_DEBUG 1\n--\nnet/mac80211/debug.h-82-\nnet/mac80211/debug.h:83:#ifdef CONFIG_MAC80211_MLME_DEBUG\nnet/mac80211/debug.h-84-#define MAC80211_MLME_DEBUG 1\n--\nnet/mac80211/debug.h-88-\nnet/mac80211/debug.h:89:#ifdef CONFIG_MAC80211_MESSAGE_TRACING\nnet/mac80211/debug.h-90-void __sdata_info(const char *fmt, ...) __printf(1, 2);\n--\nnet/mac80211/debugfs.c=632=static const struct debugfs_short_fops stats_ ##name## _ops = {\t\t\t\\\n--\nnet/mac80211/debugfs.c-636-\nnet/mac80211/debugfs.c:637:#ifdef CONFIG_MAC80211_DEBUG_COUNTERS\nnet/mac80211/debugfs.c-638-#define DEBUGFS_STATS_ADD(name)\t\t\t\t\t\\\n--\nnet/mac80211/debugfs.c=649=void debugfs_hw_add(struct ieee80211_local *local)\n--\nnet/mac80211/debugfs.c-683-\nnet/mac80211/debugfs.c:684:#ifdef CONFIG_MAC80211_DEBUG_COUNTERS\nnet/mac80211/debugfs.c-685-\tDEBUGFS_STATS_ADD(dot11TransmittedFragmentCount);\n--\nnet/mac80211/debugfs.h-6-\nnet/mac80211/debugfs.h:7:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/debugfs.h-8-void debugfs_hw_add(struct ieee80211_local *local);\n--\nnet/mac80211/debugfs_key.h-4-\nnet/mac80211/debugfs_key.h:5:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/debugfs_key.h-6-void ieee80211_debugfs_key_add(struct ieee80211_key *key);\n--\nnet/mac80211/debugfs_netdev.c=736=IEEE80211_IF_LINK_FILE(addr, conf-\u003eaddr, MAC);\nnet/mac80211/debugfs_netdev.c-737-\nnet/mac80211/debugfs_netdev.c:738:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/debugfs_netdev.c-739-IEEE80211_IF_FILE(estab_plinks, u.mesh.estab_plinks, ATOMIC);\n--\nnet/mac80211/debugfs_netdev.c=868=static void add_ibss_files(struct ieee80211_sub_if_data *sdata)\n--\nnet/mac80211/debugfs_netdev.c-872-\nnet/mac80211/debugfs_netdev.c:873:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/debugfs_netdev.c-874-\n--\nnet/mac80211/debugfs_netdev.c=937=static void add_files(struct ieee80211_sub_if_data *sdata)\n--\nnet/mac80211/debugfs_netdev.c-949-\tcase NL80211_IFTYPE_MESH_POINT:\nnet/mac80211/debugfs_netdev.c:950:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/debugfs_netdev.c-951-\t\tadd_mesh_files(sdata);\n--\nnet/mac80211/debugfs_netdev.h-12-\nnet/mac80211/debugfs_netdev.h:13:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/debugfs_netdev.h-14-void ieee80211_debugfs_remove_netdev(struct ieee80211_sub_if_data *sdata);\n--\nnet/mac80211/debugfs_sta.h-6-\nnet/mac80211/debugfs_sta.h:7:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/debugfs_sta.h-8-void ieee80211_sta_debugfs_add(struct sta_info *sta);\n--\nnet/mac80211/driver-ops.h=477=static inline void drv_sta_remove(struct ieee80211_local *local,\n--\nnet/mac80211/driver-ops.h-494-\nnet/mac80211/driver-ops.h:495:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/driver-ops.h-496-static inline void drv_vif_add_debugfs(struct ieee80211_local *local,\n--\nnet/mac80211/ieee80211_i.h=770=struct ieee80211_if_mesh {\n--\nnet/mac80211/ieee80211_i.h-850-\nnet/mac80211/ieee80211_i.h:851:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/ieee80211_i.h-852-#define IEEE80211_IFSTA_MESH_CTR_INC(msh, name)\t\\\n--\nnet/mac80211/ieee80211_i.h=1099=struct ieee80211_link_data {\n--\nnet/mac80211/ieee80211_i.h-1151-\nnet/mac80211/ieee80211_i.h:1152:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/ieee80211_i.h-1153-\tstruct dentry *debugfs_dir;\n--\nnet/mac80211/ieee80211_i.h=1157=struct ieee80211_sub_if_data {\n--\nnet/mac80211/ieee80211_i.h-1244-\nnet/mac80211/ieee80211_i.h:1245:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/ieee80211_i.h-1246-\tstruct {\n--\nnet/mac80211/ieee80211_i.h=1364=enum queue_stop_reason {\n--\nnet/mac80211/ieee80211_i.h-1379-\nnet/mac80211/ieee80211_i.h:1380:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/ieee80211_i.h-1381-struct tpt_led_trigger {\n--\nnet/mac80211/ieee80211_i.h=1448=struct ieee80211_local {\n--\nnet/mac80211/ieee80211_i.h-1628-\nnet/mac80211/ieee80211_i.h:1629:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/ieee80211_i.h-1630-\tstruct led_trigger tx_led, rx_led, assoc_led, radio_led;\n--\nnet/mac80211/ieee80211_i.h-1636-\nnet/mac80211/ieee80211_i.h:1637:#ifdef CONFIG_MAC80211_DEBUG_COUNTERS\nnet/mac80211/ieee80211_i.h-1638-\t/* SNMP counters */\n--\nnet/mac80211/ieee80211_i.h-1664-#define I802_DEBUG_INC(c) (c)++\nnet/mac80211/ieee80211_i.h:1665:#else /* CONFIG_MAC80211_DEBUG_COUNTERS */\nnet/mac80211/ieee80211_i.h-1666-#define I802_DEBUG_INC(c) do { } while (0)\nnet/mac80211/ieee80211_i.h:1667:#endif /* CONFIG_MAC80211_DEBUG_COUNTERS */\nnet/mac80211/ieee80211_i.h-1668-\n--\nnet/mac80211/ieee80211_i.h-1695-\nnet/mac80211/ieee80211_i.h:1696:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/ieee80211_i.h-1697-\tstruct local_debugfsdentries {\n--\nnet/mac80211/ieee80211_i.h=2942=u32 ieee80211_calc_expected_tx_airtime(struct ieee80211_hw *hw,\n--\nnet/mac80211/ieee80211_i.h-2945-\t\t\t\t int len, bool ampdu);\nnet/mac80211/ieee80211_i.h:2946:#ifdef CONFIG_MAC80211_NOINLINE\nnet/mac80211/ieee80211_i.h-2947-#define debug_noinline noinline\n--\nnet/mac80211/ieee80211_i.h=2978=ieee80211_uhr_cap_ie_to_sta_uhr_cap(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/ieee80211_i.h-2983-\nnet/mac80211/ieee80211_i.h:2984:#if IS_ENABLED(CONFIG_MAC80211_KUNIT_TEST)\nnet/mac80211/ieee80211_i.h-2985-#define EXPORT_SYMBOL_IF_MAC80211_KUNIT(sym) EXPORT_SYMBOL_IF_KUNIT(sym)\n--\nnet/mac80211/key.h=59=struct ieee80211_key {\n--\nnet/mac80211/key.h-122-\nnet/mac80211/key.h:123:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/key.h-124-\tstruct {\n--\nnet/mac80211/led.h=13=static inline void ieee80211_led_rx(struct ieee80211_local *local)\nnet/mac80211/led.h-14-{\nnet/mac80211/led.h:15:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/led.h-16-\tif (!atomic_read(\u0026local-\u003erx_led_active))\n--\nnet/mac80211/led.h=22=static inline void ieee80211_led_tx(struct ieee80211_local *local)\nnet/mac80211/led.h-23-{\nnet/mac80211/led.h:24:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/led.h-25-\tif (!atomic_read(\u0026local-\u003etx_led_active))\n--\nnet/mac80211/led.h-30-\nnet/mac80211/led.h:31:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/led.h-32-void ieee80211_led_assoc(struct ieee80211_local *local,\n--\nnet/mac80211/led.h=71=ieee80211_tpt_led_trig_tx(struct ieee80211_local *local, int bytes)\nnet/mac80211/led.h-72-{\nnet/mac80211/led.h:73:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/led.h-74-\tif (atomic_read(\u0026local-\u003etpt_led_active))\n--\nnet/mac80211/led.h=80=ieee80211_tpt_led_trig_rx(struct ieee80211_local *local, int bytes)\nnet/mac80211/led.h-81-{\nnet/mac80211/led.h:82:#ifdef CONFIG_MAC80211_LEDS\nnet/mac80211/led.h-83-\tif (atomic_read(\u0026local-\u003etpt_led_active))\n--\nnet/mac80211/main.c=1138=int ieee80211_register_hw(struct ieee80211_hw *hw)\n--\nnet/mac80211/main.c-1393-\nnet/mac80211/main.c:1394:#ifndef CONFIG_MAC80211_MESH\nnet/mac80211/main.c-1395-\t/* mesh depends on Kconfig, but drivers should set it if they want */\n--\nnet/mac80211/mesh.h=378=void mesh_path_refresh(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/mesh.h-380-\nnet/mac80211/mesh.h:381:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/mesh.h-382-static inline\n--\nnet/mac80211/offchannel.c=812=int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,\n--\nnet/mac80211/offchannel.c-841-\t\t\tneed_offchan = true;\nnet/mac80211/offchannel.c:842:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/offchannel.c-843-\t\tfallthrough;\n--\nnet/mac80211/rate.c=24=static DEFINE_MUTEX(rate_ctrl_mutex);\nnet/mac80211/rate.c-25-\nnet/mac80211/rate.c:26:static char *ieee80211_default_rc_algo = CONFIG_MAC80211_RC_DEFAULT;\nnet/mac80211/rate.c-27-module_param(ieee80211_default_rc_algo, charp, 0644);\n--\nnet/mac80211/rate.c=216=ieee80211_rate_control_ops_get(const char *name)\n--\nnet/mac80211/rate.c-232-\t/* Note: check for \u003e 0 is intentional to avoid clang warning */\nnet/mac80211/rate.c:233:\tif (!ops \u0026\u0026 (strlen(CONFIG_MAC80211_RC_DEFAULT) \u003e 0))\nnet/mac80211/rate.c-234-\t\t/* try built-in one if specific alg requested but not found */\nnet/mac80211/rate.c:235:\t\tops = ieee80211_try_rate_control_ops_get(CONFIG_MAC80211_RC_DEFAULT);\nnet/mac80211/rate.c-236-\n--\nnet/mac80211/rate.c-241-\nnet/mac80211/rate.c:242:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rate.c-243-static ssize_t rcname_read(struct file *file, char __user *userbuf,\n--\nnet/mac80211/rate.c=281=static void rate_control_free(struct ieee80211_local *local,\n--\nnet/mac80211/rate.c-285-\nnet/mac80211/rate.c:286:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rate.c-287-\tdebugfs_remove_recursive(local-\u003edebugfs.rcdir);\n--\nnet/mac80211/rate.h=55=static inline void rate_control_add_sta_debugfs(struct sta_info *sta)\nnet/mac80211/rate.h-56-{\nnet/mac80211/rate.h:57:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rate.h-58-\tstruct rate_control_ref *ref = sta-\u003erate_ctrl;\n--\nnet/mac80211/rate.h=67=static inline void rate_control_add_debugfs(struct ieee80211_local *local)\nnet/mac80211/rate.h-68-{\nnet/mac80211/rate.h:69:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rate.h-70-\tstruct dentry *debugfsdir;\n--\nnet/mac80211/rate.h=94=void rate_control_deinitialize(struct ieee80211_local *local);\n--\nnet/mac80211/rate.h-97-/* Rate control algorithms */\nnet/mac80211/rate.h:98:#ifdef CONFIG_MAC80211_RC_MINSTREL\nnet/mac80211/rate.h-99-int rc80211_minstrel_init(void);\n--\nnet/mac80211/rc80211_minstrel_ht.c=1059=minstrel_ht_update_stats(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)\n--\nnet/mac80211/rc80211_minstrel_ht.c-1181-\nnet/mac80211/rc80211_minstrel_ht.c:1182:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rc80211_minstrel_ht.c-1183-\t/* use fixed index if set */\n--\nnet/mac80211/rc80211_minstrel_ht.c=1595=minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,\n--\nnet/mac80211/rc80211_minstrel_ht.c-1606-\nnet/mac80211/rc80211_minstrel_ht.c:1607:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rc80211_minstrel_ht.c-1608-\tif (mp-\u003efixed_rate_idx != -1)\n--\nnet/mac80211/rc80211_minstrel_ht.c=1915=minstrel_ht_alloc(struct ieee80211_hw *hw)\n--\nnet/mac80211/rc80211_minstrel_ht.c-1948-\nnet/mac80211/rc80211_minstrel_ht.c:1949:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rc80211_minstrel_ht.c-1950-static void minstrel_ht_add_debugfs(struct ieee80211_hw *hw, void *priv,\n--\nnet/mac80211/rc80211_minstrel_ht.c=1983=static const struct rate_control_ops mac80211_minstrel_ht = {\n--\nnet/mac80211/rc80211_minstrel_ht.c-1993-\t.free = minstrel_ht_free,\nnet/mac80211/rc80211_minstrel_ht.c:1994:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rc80211_minstrel_ht.c-1995-\t.add_debugfs = minstrel_ht_add_debugfs,\n--\nnet/mac80211/rc80211_minstrel_ht.h=75=struct minstrel_priv {\n--\nnet/mac80211/rc80211_minstrel_ht.h-85-\nnet/mac80211/rc80211_minstrel_ht.h:86:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/rc80211_minstrel_ht.h-87-\t/*\n--\nnet/mac80211/rx.c=1051=static void ieee80211_verify_alignment(struct ieee80211_rx_data *rx)\nnet/mac80211/rx.c-1052-{\nnet/mac80211/rx.c:1053:#ifdef CONFIG_MAC80211_VERBOSE_DEBUG\nnet/mac80211/rx.c-1054-\tWARN_ON_ONCE((unsigned long)rx-\u003eskb-\u003edata \u0026 1);\n--\nnet/mac80211/rx.c=2794=ieee80211_deliver_skb(struct ieee80211_rx_data *rx)\n--\nnet/mac80211/rx.c-2893-\nnet/mac80211/rx.c:2894:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/rx.c-2895-static bool\n--\nnet/mac80211/rx.c=2961=ieee80211_rx_mesh_data(struct ieee80211_sub_if_data *sdata, struct sta_info *sta,\n--\nnet/mac80211/rx.c-2963-{\nnet/mac80211/rx.c:2964:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/rx.c-2965-\tstruct ieee80211_if_mesh *ifmsh = \u0026sdata-\u003eu.mesh;\n--\nnet/mac80211/sta_info.c=72=static const struct rhashtable_params sta_rht_params = {\n--\nnet/mac80211/sta_info.c-77-\t.key_len = ETH_ALEN,\nnet/mac80211/sta_info.c:78:\t.max_size = CONFIG_MAC80211_STA_HASH_MAX_SIZE,\nnet/mac80211/sta_info.c-79-};\n--\nnet/mac80211/sta_info.c=81=static const struct rhashtable_params link_sta_rht_params = {\n--\nnet/mac80211/sta_info.c-86-\t.key_len = ETH_ALEN,\nnet/mac80211/sta_info.c:87:\t.max_size = CONFIG_MAC80211_STA_HASH_MAX_SIZE,\nnet/mac80211/sta_info.c-88-};\n--\nnet/mac80211/sta_info.c=468=void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)\n--\nnet/mac80211/sta_info.c-506-\tkfree(rcu_dereference_raw(sta-\u003esta.rates));\nnet/mac80211/sta_info.c:507:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-508-\tkfree(sta-\u003emesh);\n--\nnet/mac80211/sta_info.c=633=__sta_info_alloc(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/sta_info.c-667-\twiphy_work_init(\u0026sta-\u003eampdu_mlme.work, ieee80211_ba_session_work);\nnet/mac80211/sta_info.c:668:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-669-\tif (ieee80211_vif_is_mesh(\u0026sdata-\u003evif)) {\n--\nnet/mac80211/sta_info.c-795-\tsta_info_free_link(\u0026sta-\u003edeflink);\nnet/mac80211/sta_info.c:796:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-797-\tkfree(sta-\u003emesh);\n--\nnet/mac80211/sta_info.c=1107=static void __sta_info_recalc_tim(struct sta_info *sta, bool ignore_pending)\n--\nnet/mac80211/sta_info.c-1121-\t\tps = \u0026sta-\u003esdata-\u003ebss-\u003eps;\nnet/mac80211/sta_info.c:1122:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-1123-\t} else if (ieee80211_vif_is_mesh(\u0026sta-\u003esdata-\u003evif)) {\n--\nnet/mac80211/sta_info.c=2728=static inline u64 sta_get_stats_bytes(struct ieee80211_sta_rx_stats *rxstats)\n--\nnet/mac80211/sta_info.c-2740-\nnet/mac80211/sta_info.c:2741:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-2742-static void sta_set_mesh_sinfo(struct sta_info *sta,\n--\nnet/mac80211/sta_info.c=3038=void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,\n--\nnet/mac80211/sta_info.c-3223-\nnet/mac80211/sta_info.c:3224:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.c-3225-\tif (ieee80211_vif_is_mesh(\u0026sdata-\u003evif))\n--\nnet/mac80211/sta_info.h=525=struct link_sta_info {\n--\nnet/mac80211/sta_info.h-576-\nnet/mac80211/sta_info.h:577:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/sta_info.h-578-\tstruct dentry *debugfs_dir;\n--\nnet/mac80211/sta_info.h=714=struct sta_info {\n--\nnet/mac80211/sta_info.h-731-\nnet/mac80211/sta_info.h:732:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.h-733-\tstruct mesh_sta *mesh;\n--\nnet/mac80211/sta_info.h-772-\nnet/mac80211/sta_info.h:773:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/sta_info.h-774-\tstruct dentry *debugfs_dir;\n--\nnet/mac80211/sta_info.h=799=static inline enum nl80211_plink_state sta_plink_state(struct sta_info *sta)\nnet/mac80211/sta_info.h-800-{\nnet/mac80211/sta_info.h:801:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/sta_info.h-802-\treturn sta-\u003emesh-\u003eplink_state;\n--\nnet/mac80211/tests/.kunitconfig=2=CONFIG_CFG80211=y\nnet/mac80211/tests/.kunitconfig:3:CONFIG_MAC80211=y\nnet/mac80211/tests/.kunitconfig:4:CONFIG_MAC80211_KUNIT_TEST=y\n--\nnet/mac80211/tests/Makefile=1=mac80211-tests-y += module.o util.o elems.o mfp.o tpe.o chan-mode.o s1g_tim.o ttlm.o\nnet/mac80211/tests/Makefile-2-\nnet/mac80211/tests/Makefile:3:obj-$(CONFIG_MAC80211_KUNIT_TEST) += mac80211-tests.o\n--\nnet/mac80211/trace.c-13-\nnet/mac80211/trace.c:14:#ifdef CONFIG_MAC80211_MESSAGE_TRACING\nnet/mac80211/trace.c-15-void __sdata_info(const char *fmt, ...)\n--\nnet/mac80211/trace_msg.h-6-\nnet/mac80211/trace_msg.h:7:#ifdef CONFIG_MAC80211_MESSAGE_TRACING\nnet/mac80211/trace_msg.h-8-\n--\nnet/mac80211/tx.c=270=ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)\n--\nnet/mac80211/tx.c-290-\t\t\t ieee80211_is_data(hdr-\u003eframe_control))) {\nnet/mac80211/tx.c:291:#ifdef CONFIG_MAC80211_VERBOSE_DEBUG\nnet/mac80211/tx.c-292-\t\t\tsdata_info(tx-\u003esdata,\n--\nnet/mac80211/tx.c=1691=static bool ieee80211_tx_frags(struct ieee80211_local *local,\n--\nnet/mac80211/tx.c-1704-\nnet/mac80211/tx.c:1705:#ifdef CONFIG_MAC80211_VERBOSE_DEBUG\nnet/mac80211/tx.c-1706-\t\tif (WARN_ON_ONCE(q \u003e= local-\u003ehw.queues)) {\n--\nnet/mac80211/tx.c=2513=int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-2537-\t\tbreak;\nnet/mac80211/tx.c:2538:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/tx.c-2539-\tcase NL80211_IFTYPE_MESH_POINT:\n--\nnet/mac80211/tx.c=2656=static struct sk_buff *ieee80211_build_hdr(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-2682-\nnet/mac80211/tx.c:2683:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/tx.c-2684-\tif (local-\u003eforce_tx_status)\n--\nnet/mac80211/tx.c-2755-\t\tbreak;\nnet/mac80211/tx.c:2756:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/tx.c-2757-\tcase NL80211_IFTYPE_MESH_POINT:\n--\nnet/mac80211/tx.c-2943-\t\t !ieee80211_is_our_addr(sdata, skb-\u003edata + ETH_ALEN, NULL)))) {\nnet/mac80211/tx.c:2944:#ifdef CONFIG_MAC80211_VERBOSE_DEBUG\nnet/mac80211/tx.c-2945-\t\tnet_info_ratelimited(\"%s: dropped frame to %pM (unauthorized port)\\n\",\n--\nnet/mac80211/tx.c-3017-\nnet/mac80211/tx.c:3018:#ifdef CONFIG_MAC80211_MESH\nnet/mac80211/tx.c-3019-\tif (meshhdrlen \u003e 0)\n--\nnet/mac80211/tx.c-3064-\t\t link_id != IEEE80211_LINK_UNSPECIFIED) {\nnet/mac80211/tx.c:3065:#ifdef CONFIG_MAC80211_VERBOSE_DEBUG\nnet/mac80211/tx.c-3066-\t\t\tnet_info_ratelimited(\"%s: dropped frame to %pM with bad link ID request (%d vs. %d)\\n\",\n--\nnet/mac80211/tx.c=3747=void __ieee80211_xmit_fast(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-3793-\nnet/mac80211/tx.c:3794:#ifdef CONFIG_MAC80211_DEBUGFS\nnet/mac80211/tx.c-3795-\tif (local-\u003eforce_tx_status)\n"
} |
| 5/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 16806 output: 41 thoughts: 46 Thoughts: Here's a breakdown of my thought process, as if I were analyzing those code sections: **Diving Deep into mac80211 TX Path** Alright, let's get into the nitty-gritty of the mac80211 transmit path. I need to understand how this code handles the complex dance of getting a packet from the driver to the air. Specifically, I'm focusing on `net/mac80211/tx.c`. My initial targets are lines 1860-1900 and 4680-4780. Those sections likely represent critical parts of the TX process – perhaps related to packet scheduling, rate adaptation, hardware interactions, or maybe even power save handling on the transmit side. Understanding those specific areas will offer good context for the rest of the file. I also need to see how the code is configured, so I'll be referring to the `Kconfig` file. I'll need to check the dependencies and any conditional compilation that's going on. This will help me understand which features are enabled or disabled based on the chosen configuration, and how these settings influence the code paths in `tx.c` that I'm examining. I'll be looking for any hints on how these features relate to different hardware platforms or protocol implementations. |
| 6/2 | 2026/09/07 14:48 | tool | read-file |
0mArgs:{
"File": "net/mac80211/tx.c",
"FirstLine": 1860,
"LineCount": 40
}Results: {
"Contents": "1860:\t\n1861:\t/*\n1862:\t * Late handlers can be called while the sta lock is held. Handlers that can\n1863:\t * cause packets to be generated will cause deadlock!\n1864:\t */\n1865:\tstatic int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)\n1866:\t{\n1867:\t\tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-\u003eskb);\n1868:\t\tieee80211_tx_result res = TX_CONTINUE;\n1869:\t\n1870:\t\tif (!ieee80211_hw_check(\u0026tx-\u003elocal-\u003ehw, HAS_RATE_CONTROL))\n1871:\t\t\tCALL_TXH(ieee80211_tx_h_rate_ctrl);\n1872:\t\n1873:\t\tif (unlikely(info-\u003eflags \u0026 IEEE80211_TX_INTFL_RETRANSMISSION)) {\n1874:\t\t\t__skb_queue_tail(\u0026tx-\u003eskbs, tx-\u003eskb);\n1875:\t\t\ttx-\u003eskb = NULL;\n1876:\t\t\tgoto txh_done;\n1877:\t\t}\n1878:\t\n1879:\t\tCALL_TXH(ieee80211_tx_h_check_offchannel);\n1880:\t\tCALL_TXH(ieee80211_tx_h_michael_mic_add);\n1881:\t\tCALL_TXH(ieee80211_tx_h_sequence);\n1882:\t\tCALL_TXH(ieee80211_tx_h_fragment);\n1883:\t\t/* handlers after fragment must be aware of tx info fragmentation! */\n1884:\t\tCALL_TXH(ieee80211_tx_h_stats);\n1885:\t\tCALL_TXH(ieee80211_tx_h_encrypt);\n1886:\t\tif (!ieee80211_hw_check(\u0026tx-\u003elocal-\u003ehw, HAS_RATE_CONTROL))\n1887:\t\t\tCALL_TXH(ieee80211_tx_h_calculate_duration);\n1888:\t#undef CALL_TXH\n1889:\t\n1890:\t txh_done:\n1891:\t\tif (unlikely(res == TX_DROP)) {\n1892:\t\t\ttx-\u003esdata-\u003etx_handlers_drop++;\n1893:\t\t\tif (tx-\u003eskb)\n1894:\t\t\t\tieee80211_free_txskb(\u0026tx-\u003elocal-\u003ehw, tx-\u003eskb);\n1895:\t\t\telse\n1896:\t\t\t\tieee80211_purge_tx_queue(\u0026tx-\u003elocal-\u003ehw, \u0026tx-\u003eskbs);\n1897:\t\t\treturn -1;\n1898:\t\t} else if (unlikely(res == TX_QUEUED)) {\n1899:\t\t\tI802_DEBUG_INC(tx-\u003elocal-\u003etx_handlers_queued);\n"
} |
| 7/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 17990 output: 37 thoughts: 16 Thoughts: Here's my attempt at summarizing the thought process, tailored for an expert audience: **Investigating MAC80211 Dependencies in Kconfig** Okay, so I need to dig into the Kconfig files related to MAC80211. Specifically, I want to map out the dependencies. Knowing these dependencies will give me a clear picture of how different parts of the wireless stack are configured and how they relate to each other. This is crucial for understanding the impact of any changes I make, debugging potential issues, or even simply for documentation purposes. I need a clear view of how features are enabled or disabled and how different configurations might interact. I'll need to look for dependencies on other kernel subsystems, driver configurations, and any external libraries. Let's start with a quick search... time to see what those Kconfig files reveal! |
| 8/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "config MAC80211\\b",
"PathPrefix": "net/mac80211"
}Results: {
"Output": "net/mac80211/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\nnet/mac80211/Kconfig:2:config MAC80211\nnet/mac80211/Kconfig-3-\ttristate \"Generic IEEE 802.11 Networking Stack (mac80211)\"\n"
} |
| 9/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 18319 output: 37 thoughts: 25 Thoughts: Okay, let's dive into this. I'm going to start by examining the `net/mac80211/Kconfig` file, specifically the first 40 lines. This is where the core configuration options for the mac80211 wireless stack are likely defined. I expect to see the basic structure of the configuration options: menu entries, default values, help texts, and potentially dependencies on other kernel features or hardware. I'm looking for the foundational building blocks, the top-level categories under which more specific wireless features are grouped. This will give me a quick understanding of the scope and structure of the configurable elements within the driver. I will be looking for: **mac80211 Configuration Overview** Alright, I'm now in the file. I'm going to quickly skim the first 40 lines. Immediately I'm trying to identify the overall structure. What are the major sections? What are the key variables defined? I'm anticipating that these lines will define the core module, perhaps its dependencies, and a few high-level options like enabling or disabling the entire subsystem. Are there any initial defaults set, or any conditional dependencies that jumps out? This is the initial setup; the foundation upon which more specific settings build. I am going to try and identify how this module is enabled. I need to get a high-level view of the configuration options for the mac80211 stack. |
| 10/2 | 2026/09/07 14:48 | tool | read-file |
0mArgs:{
"File": "net/mac80211/Kconfig",
"FirstLine": 1,
"LineCount": 40
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig MAC80211\n 3:\t\ttristate \"Generic IEEE 802.11 Networking Stack (mac80211)\"\n 4:\t\tdepends on CFG80211\n 5:\t\tselect CRYPTO\n 6:\t\tselect CRYPTO_LIB_AES_CBC_MACS\n 7:\t\tselect CRYPTO_LIB_ARC4\n 8:\t\tselect CRYPTO_AES\n 9:\t\tselect CRYPTO_CCM\n 10:\t\tselect CRYPTO_GCM\n 11:\t\tselect CRC32\n 12:\t\thelp\n 13:\t\t This option enables the hardware independent IEEE 802.11\n 14:\t\t networking stack.\n 15:\t\n 16:\tcomment \"CFG80211 needs to be enabled for MAC80211\"\n 17:\t\tdepends on CFG80211=n\n 18:\t\n 19:\tif MAC80211 != n\n 20:\t\n 21:\tconfig MAC80211_HAS_RC\n 22:\t\tbool\n 23:\t\n 24:\tconfig MAC80211_RC_MINSTREL\n 25:\t\tbool \"Minstrel\" if EXPERT\n 26:\t\tselect MAC80211_HAS_RC\n 27:\t\tdefault y\n 28:\t\thelp\n 29:\t\t This option enables the 'minstrel' TX rate control algorithm\n 30:\t\n 31:\tchoice\n 32:\t\tprompt \"Default rate control algorithm\"\n 33:\t\tdepends on MAC80211_HAS_RC\n 34:\t\tdefault MAC80211_RC_DEFAULT_MINSTREL\n 35:\t\thelp\n 36:\t\t This option selects the default rate control algorithm\n 37:\t\t mac80211 will use. Note that this default can still be\n 38:\t\t overridden through the ieee80211_default_rc_algo module\n 39:\t\t parameter if different algorithms are available.\n 40:\t\n"
} |
| 11/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 19235 output: 35 thoughts: 559 Thoughts: **Analyzing the mac80211 TX Path Patch** Okay, let's break down this patch. My initial thought is to understand the core change: It's a relocation of the off-channel scanning check within the mac80211 transmit path. Previously, this check was performed in two places, `ieee80211_tx_h_check_assoc()` and `ieee80211_8023_xmit()`, very early in the transmit process. The patch strategically introduces a new transmit handler, `ieee80211_tx_h_check_offchannel()`, and integrates it later in the process via `invoke_tx_handlers_late()`. This also means the duplicate checks in the previous two functions have been removed. My next step is to evaluate whether this change warrants fuzzing. The answer is a clear yes. mac80211 is readily accessible for testing, especially in virtualized environments using mac80211_hwsim, netlink/nl80211, and network sockets with packet injection. The modification directly impacts executable kernel networking logic – specifically, the TX path handling during scanning and off-channel transitions. Moving this check to a "late" handler alters the packet processing timeline, introducing potential vulnerabilities. It could have significant implications for state transitions, and introduce or reveal race conditions between scanning operations and packet transmission. It's also worth investigating any shifts in skb lifecycles or queue handling that this change might cause. Now, let's identify the specific functions to focus on. I'll need to check if `ieee80211_tx_h_check_offchannel` is non-static or if the `debug_noinline` macro causes it to be inlined. I see that this is conditional. `CONFIG_MAC80211_NOINLINE` determines if `debug_noinline` is defined as `noinline` (which produces a symbol) or is an empty definition, and therefore, an inlined function. I'll have to investigate if this configuration option is set to determine if we should look for this symbol. Finally, I'll need to identify potential entry points and handlers that are associated with `invoke_tx_handlers_late()` and frame transmission. I'll have to grep for `invoke_tx_handlers_late` and caller functions in `net/mac80211/tx.c` to understand where this new handler is actually being invoked. |
| 12/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "invoke_tx_handlers_late",
"PathPrefix": "net/mac80211"
}Results: {
"Output": "net/mac80211/tx.c=1828=static int invoke_tx_handlers_early(struct ieee80211_tx_data *tx)\n--\nnet/mac80211/tx.c-1864- */\nnet/mac80211/tx.c:1865:static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)\nnet/mac80211/tx.c-1866-{\n--\nnet/mac80211/tx.c=1906=static int invoke_tx_handlers(struct ieee80211_tx_data *tx)\n--\nnet/mac80211/tx.c-1911-\t\treturn r;\nnet/mac80211/tx.c:1912:\treturn invoke_tx_handlers_late(tx);\nnet/mac80211/tx.c-1913-}\n--\nnet/mac80211/tx.c=1958=static bool ieee80211_tx(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-1995-\nnet/mac80211/tx.c:1996:\tif (!invoke_tx_handlers_late(\u0026tx))\nnet/mac80211/tx.c-1997-\t\tresult = __ieee80211_tx(local, \u0026tx.skbs, tx.sta, txpending);\n--\nnet/mac80211/tx.c=3888=struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,\n--\nnet/mac80211/tx.c-4015-\t} else {\nnet/mac80211/tx.c:4016:\t\tif (invoke_tx_handlers_late(\u0026tx))\nnet/mac80211/tx.c-4017-\t\t\tgoto begin;\n"
} |
| 13/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 20911 output: 43 thoughts: 97 Thoughts: Here's my thought process, as I analyze these functions related to 802.11 transmission: **Deconstructing the 802.11 Transmit Path** Okay, first things first, I'm looking at a sequence of functions that likely represent the core of the 802.11 transmission process in this codebase. I see `ieee80211_tx`, which is the starting point, the entry function for initiating a transmission. Then we have `ieee80211_tx_dequeue`, which tells me that this architecture likely uses a queue-based system for managing outgoing packets – that makes perfect sense. Next, `ieee80211_8023_xmit` is interesting. The "8023" naming strongly suggests it's involved in the Ethernet encapsulation process, converting the 802.11 frames to an Ethernet format, perhaps for a bridge or a wired connection in a mixed network. `invoke_tx_handlers_late` hints at a callback or a post-processing stage, where some delayed actions are performed after the core transmission process is completed. This could be things like updating statistics, managing retries, or freeing buffers. Finally, `ieee80211_tx_h_check_offchannel` is immediately intriguing. The "offchannel" part implies some form of channel scanning or control, which suggests the possibility of handling transmission on non-primary channels, maybe for features like DFS (Dynamic Frequency Selection), or channel hopping in some circumstances. To fully understand the context of `ieee80211_8023_xmit`, I should investigate its callers. Understanding what *calls* that function will illuminate how and where the Ethernet-related encapsulation happens in the overall transmission flow. This will likely provide valuable context on how the driver handles different frame types and network interfaces. It's a key part of the puzzle. |
| 14/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "ieee80211_8023_xmit",
"PathPrefix": "net/mac80211"
}Results: {
"Output": "net/mac80211/tx.c=4667=static bool ieee80211_tx_8023(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-4686-\nnet/mac80211/tx.c:4687:static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,\nnet/mac80211/tx.c-4688-\t\t\t\tstruct net_device *dev, struct sta_info *sta,\n--\nnet/mac80211/tx.c=4790=static void __ieee80211_subif_start_xmit_8023(struct sk_buff *skb,\n--\nnet/mac80211/tx.c-4835-\tsk_pacing_shift_update(skb-\u003esk, sdata-\u003elocal-\u003ehw.tx_sk_pacing_shift);\nnet/mac80211/tx.c:4836:\tieee80211_8023_xmit(sdata, dev, sta, key, skb);\nnet/mac80211/tx.c-4837-\tgoto out;\n"
} |
| 15/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 21816 output: 35 thoughts: 54 Thoughts: Okay, here's my take on those thoughts, framed as my own: **Investigating Potential Bottlenecks in the 802.3 Transmission Path** Right, let's dive into this. I'm thinking we need to specifically scrutinize the `__ieee80211_subif_start_xmit_8023` function and its counterpart, `ieee80211_subif_start_xmit_8023`. We need to understand the flow here, especially around 802.3 frames, which is often a source of contention. I'll need to examine not just these two functions themselves, but also where they're being called from. Are there other functions or code paths triggering these functions? Are there particular callers or contexts that seem to be exhibiting performance issues, or at least that warrant closer inspection? This is where the real actionable insight is likely to lie. Understanding the call stack and data flow around these functions is crucial to identifying any bottlenecks. I’ll start tracing and profiling to determine the impact. |
| 16/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "subif_start_xmit",
"PathPrefix": "net/mac80211"
}Results: {
"Output": "net/mac80211/ieee80211_i.h=2228=netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,\nnet/mac80211/ieee80211_i.h-2229-\t\t\t\t\t struct net_device *dev);\nnet/mac80211/ieee80211_i.h:2230:netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,\nnet/mac80211/ieee80211_i.h-2231-\t\t\t\t struct net_device *dev);\nnet/mac80211/ieee80211_i.h:2232:netdev_tx_t ieee80211_subif_start_xmit_8023(struct sk_buff *skb,\nnet/mac80211/ieee80211_i.h-2233-\t\t\t\t\t struct net_device *dev);\nnet/mac80211/ieee80211_i.h:2234:void __ieee80211_subif_start_xmit(struct sk_buff *skb,\nnet/mac80211/ieee80211_i.h-2235-\t\t\t\t struct net_device *dev,\n--\nnet/mac80211/iface.c=941=static const struct net_device_ops ieee80211_dataif_ops = {\n--\nnet/mac80211/iface.c-944-\t.ndo_uninit\t\t= ieee80211_uninit,\nnet/mac80211/iface.c:945:\t.ndo_start_xmit\t\t= ieee80211_subif_start_xmit,\nnet/mac80211/iface.c-946-\t.ndo_set_rx_mode\t= ieee80211_set_multicast_list,\n--\nnet/mac80211/iface.c=1047=static const struct net_device_ops ieee80211_dataif_8023_ops = {\n--\nnet/mac80211/iface.c-1050-\t.ndo_uninit\t\t= ieee80211_uninit,\nnet/mac80211/iface.c:1051:\t.ndo_start_xmit\t\t= ieee80211_subif_start_xmit_8023,\nnet/mac80211/iface.c-1052-\t.ndo_set_rx_mode\t= ieee80211_set_multicast_list,\n--\nnet/mac80211/status.c=537=static void ieee80211_tdls_td_tx_handle(struct ieee80211_local *local,\n--\nnet/mac80211/status.c-566-\nnet/mac80211/status.c:567:\t\t\tieee80211_subif_start_xmit(teardown_skb, skb-\u003edev);\nnet/mac80211/status.c-568-\t\t}\n--\nnet/mac80211/tdls.c=997=ieee80211_tdls_prep_mgmt_packet(struct wiphy *wiphy, struct net_device *dev,\n--\nnet/mac80211/tdls.c-1122-\tlocal_bh_disable();\nnet/mac80211/tdls.c:1123:\t__ieee80211_subif_start_xmit(skb, dev, flags,\nnet/mac80211/tdls.c-1124-\t\t\t\t IEEE80211_TX_CTRL_MLO_LINK_UNSPEC, NULL);\n--\nnet/mac80211/tx.c=4352=EXPORT_SYMBOL(ieee80211_txq_schedule_start);\nnet/mac80211/tx.c-4353-\nnet/mac80211/tx.c:4354:void __ieee80211_subif_start_xmit(struct sk_buff *skb,\nnet/mac80211/tx.c-4355-\t\t\t\t struct net_device *dev,\n--\nnet/mac80211/tx.c=4542=static void ieee80211_mlo_multicast_tx_one(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-4552-\tctrl_flags |= u32_encode_bits(link_id, IEEE80211_TX_CTRL_MLO_LINK);\nnet/mac80211/tx.c:4553:\t__ieee80211_subif_start_xmit(out, sdata-\u003edev, 0, ctrl_flags, NULL);\nnet/mac80211/tx.c-4554-}\n--\nnet/mac80211/tx.c=4556=static void ieee80211_mlo_multicast_tx(struct net_device *dev,\n--\nnet/mac80211/tx.c-4567-\nnet/mac80211/tx.c:4568:\t\t__ieee80211_subif_start_xmit(skb, sdata-\u003edev, 0, ctrl_flags,\nnet/mac80211/tx.c-4569-\t\t\t\t\t NULL);\n--\nnet/mac80211/tx.c-4580-/**\nnet/mac80211/tx.c:4581: * ieee80211_subif_start_xmit - netif start_xmit function for 802.3 vifs\nnet/mac80211/tx.c-4582- * @skb: packet to be sent\n--\nnet/mac80211/tx.c-4588- */\nnet/mac80211/tx.c:4589:netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,\nnet/mac80211/tx.c-4590-\t\t\t\t struct net_device *dev)\n--\nnet/mac80211/tx.c-4608-\t\twhile ((skb = __skb_dequeue(\u0026queue)))\nnet/mac80211/tx.c:4609:\t\t\t__ieee80211_subif_start_xmit(skb, dev, 0,\nnet/mac80211/tx.c-4610-\t\t\t\t\t\t IEEE80211_TX_CTRL_MLO_LINK_UNSPEC,\n--\nnet/mac80211/tx.c-4619-normal:\nnet/mac80211/tx.c:4620:\t\t__ieee80211_subif_start_xmit(skb, dev, 0,\nnet/mac80211/tx.c-4621-\t\t\t\t\t IEEE80211_TX_CTRL_MLO_LINK_UNSPEC,\n--\nnet/mac80211/tx.c=4687=static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-4714-\t\t\t/* fall back to non-offload slow path */\nnet/mac80211/tx.c:4715:\t\t\t__ieee80211_subif_start_xmit(skb, dev, 0,\nnet/mac80211/tx.c-4716-\t\t\t\t\t\t IEEE80211_TX_CTRL_MLO_LINK_UNSPEC,\n--\nnet/mac80211/tx.c=4770=static bool ieee80211_check_mcast_offload(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-4789-\nnet/mac80211/tx.c:4790:static void __ieee80211_subif_start_xmit_8023(struct sk_buff *skb,\nnet/mac80211/tx.c-4791-\t\t\t\t\t struct net_device *dev)\n--\nnet/mac80211/tx.c-4839-skip_offload:\nnet/mac80211/tx.c:4840:\tieee80211_subif_start_xmit(skb, dev);\nnet/mac80211/tx.c-4841-out:\n--\nnet/mac80211/tx.c-4844-\nnet/mac80211/tx.c:4845:netdev_tx_t ieee80211_subif_start_xmit_8023(struct sk_buff *skb,\nnet/mac80211/tx.c-4846-\t\t\t\t\t struct net_device *dev)\n--\nnet/mac80211/tx.c-4862-\t\twhile ((skb = __skb_dequeue(\u0026queue)))\nnet/mac80211/tx.c:4863:\t\t\t__ieee80211_subif_start_xmit_8023(skb, dev);\nnet/mac80211/tx.c-4864-\t} else {\nnet/mac80211/tx.c:4865:\t\t__ieee80211_subif_start_xmit_8023(skb, dev);\nnet/mac80211/tx.c-4866-\t}\n--\nnet/mac80211/tx.c=6503=int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,\n--\nnet/mac80211/tx.c-6610-\tlocal_bh_disable();\nnet/mac80211/tx.c:6611:\t__ieee80211_subif_start_xmit(skb, skb-\u003edev, flags, ctrl_flags, cookie);\nnet/mac80211/tx.c-6612-\tlocal_bh_enable();\n--\nnet/mac80211/tx.c=6617=int ieee80211_probe_mesh_link(struct wiphy *wiphy, struct net_device *dev,\n--\nnet/mac80211/tx.c-6638-\tlocal_bh_disable();\nnet/mac80211/tx.c:6639:\t__ieee80211_subif_start_xmit(skb, skb-\u003edev, 0,\nnet/mac80211/tx.c-6640-\t\t\t\t IEEE80211_TX_CTRL_SKIP_MPATH_LOOKUP,\n"
} |
| 17/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 25093 output: 33 thoughts: 179 Thoughts: **Analyzing 802.11 TX Path Symbols and Dependencies** Okay, let's dive into this. First, I need to get a handle on the key symbols involved in the 802.11 transmit path. I've got a list here: `ieee80211_tx_h_check_offchannel`, `invoke_tx_handlers_late`, `ieee80211_8023_xmit`, `ieee80211_subif_start_xmit`, and `ieee80211_subif_start_xmit_8023`. These seem like the primary entry points and handlers I need to trace. Now, to understand their context, I need to check the relevant configuration options, specifically `CONFIG_MAC80211`. Right, `CONFIG_MAC80211` has a dependency on `CONFIG_CFG80211`, which is to be expected. I have to make sure that nothing else is required, though, just in case there's something non-obvious, or something specific to the kernel version. So I'll go back and check the `Kconfig` files in both `net/mac80211/` and `net/wireless/` just to be thorough and verify there are no hidden requirements. Good, good. With this initial framework, I should be able to navigate the code more effectively. |
| 18/2 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "config CFG80211\\b",
"PathPrefix": "net/wireless"
}Results: {
"Output": "net/wireless/Kconfig=14=config WEXT_PRIV\n--\nnet/wireless/Kconfig-16-\nnet/wireless/Kconfig:17:config CFG80211\nnet/wireless/Kconfig-18-\ttristate \"cfg80211 - wireless configuration API\"\n"
} |
| 19/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 25709 output: 32 thoughts: 20 Thoughts: Here's my summary, as if I were thinking these thoughts: **Examining the Wireless Configuration Options** Okay, time to dive into the wireless configuration options. My initial focus is the `net/wireless/Kconfig` file, specifically around lines 1 through 30. That's usually where the top-level definitions and perhaps the main menu entries are located. I'll bet it's the right place to begin understanding the overall structure and dependencies of the wireless networking configuration options. Let's see what the base configuration options are. I expect to get a feel for how various wireless technologies or features are initially enabled or disabled. This should give me a good lay of the land, helping me navigate the more specific, detailed configurations later on. |
| 20/2 | 2026/09/07 14:48 | tool | read-file |
0mArgs:{
"File": "net/wireless/Kconfig",
"FirstLine": 1,
"LineCount": 35
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: GPL-2.0-only\n 2:\tconfig WIRELESS_EXT\n 3:\t\tbool\n 4:\t\n 5:\tconfig WEXT_CORE\n 6:\t\tdef_bool y\n 7:\t\tdepends on CFG80211_WEXT || WIRELESS_EXT\n 8:\t\n 9:\tconfig WEXT_PROC\n 10:\t\tdef_bool y\n 11:\t\tdepends on PROC_FS\n 12:\t\tdepends on WEXT_CORE\n 13:\t\n 14:\tconfig WEXT_PRIV\n 15:\t\tbool\n 16:\t\n 17:\tconfig CFG80211\n 18:\t\ttristate \"cfg80211 - wireless configuration API\"\n 19:\t\tdepends on RFKILL || !RFKILL\n 20:\t\tselect FW_LOADER\n 21:\t\tselect CRC32\n 22:\t\t# may need to update this when certificates are changed and are\n 23:\t\t# using a different algorithm, though right now they shouldn't\n 24:\t\t# (this is here rather than below to allow it to be a module)\n 25:\t\tselect CRYPTO_SHA256 if CFG80211_USE_KERNEL_REGDB_KEYS\n 26:\t\thelp\n 27:\t\t cfg80211 is the Linux wireless LAN (802.11) configuration API.\n 28:\t\t Enable this if you have a wireless device.\n 29:\t\n 30:\t\t For more information refer to documentation on the wireless wiki:\n 31:\t\n 32:\t\t https://wireless.wiki.kernel.org/en/developers/Documentation/cfg80211\n 33:\t\n 34:\t\t When built as a module it will be called cfg80211.\n 35:\t\n"
} |
| 21/2 | 2026/09/07 14:48 | llm | patch-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 26397 output: 282 thoughts: 388 Thoughts: **My Configuration Evaluation**
Okay, so I need to figure out the right kernel configurations for this code. Let me see... It looks like I need `MAC80211`, `CFG80211`, and possibly `NL80211` or even `MAC80211_HWSIM`? Wait a minute, `MAC80211` and `CFG80211` are *the* direct configuration options for compiling this particular code. I should probably check if `MAC80211_HWSIM` is a relevant driver option, or if `MAC80211` and `CFG80211` alone are good enough.
Let me just quickly check the Kconfig, ah yes, `CONFIG_MAC80211` *depends* on `CONFIG_CFG80211`. Right, so `MAC80211` and `CFG80211` it is.
Now, let's just make sure I haven't missed anything important in my assessment. Let's do a quick double-check:
1. Is this patch even modifying reachable code? Yup, it's messing with the transmit path in `mac80211`, specifically handling off-channel frame filtering during scanning. That's definitely relevant.
2. Is this even worth fuzzing? Yeah, absolutely. I'm setting `WorthFuzzing=true`.
3. Right, the `EnableConfigs` are `MAC80211` and `CFG80211`. Just to confirm.
4. And finally, the `FocusSymbols` are:
* `ieee80211_tx_h_check_offchannel`
* `invoke_tx_handlers_late`
* `ieee80211_tx_h_check_assoc`
* `ieee80211_8023_xmit`
* `ieee80211_subif_start_xmit`
* `ieee80211_subif_start_xmit_8023`
Okay, that seems like a comprehensive list. I'm confident with this, so let's call `set-results`.
|
| 22/2 | 2026/09/07 14:48 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"MAC80211",
"CFG80211"
],
"FocusSymbols": [
"ieee80211_tx_h_check_offchannel",
"invoke_tx_handlers_late",
"ieee80211_tx_h_check_assoc",
"ieee80211_8023_xmit",
"ieee80211_subif_start_xmit",
"ieee80211_subif_start_xmit_8023"
],
"Reasoning": "The patch refactors the mac80211 TX path by consolidating off-channel frame dropping during software scanning into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked via invoke_tx_handlers_late(), while removing redundant checks from ieee80211_tx_h_check_assoc() and ieee80211_8023_xmit(). This modifies reachable network transmission logic accessible via standard virtualized wireless interfaces (such as mac80211_hwsim), making it suitable for fuzzing.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"MAC80211",
"CFG80211"
],
"FocusSymbols": [
"ieee80211_tx_h_check_offchannel",
"invoke_tx_handlers_late",
"ieee80211_tx_h_check_assoc",
"ieee80211_8023_xmit",
"ieee80211_subif_start_xmit",
"ieee80211_subif_start_xmit_8023"
],
"Reasoning": "The patch refactors the mac80211 TX path by consolidating off-channel frame dropping during software scanning into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked via invoke_tx_handlers_late(), while removing redundant checks from ieee80211_tx_h_check_assoc() and ieee80211_8023_xmit(). This modifies reachable network transmission logic accessible via standard virtualized wireless interfaces (such as mac80211_hwsim), making it suitable for fuzzing.",
"WorthFuzzing": true
} |
| 23/1 | 2026/09/07 14:48 | action | If |
0mArgs:{
"WorthFuzzing": true
}Results: null |
| 24/2 | 2026/09/07 14:48 | agent | kmsan-evaluator |
0mModel:core Args: null Results: {
"KMSANReasoning": "The patch refactors off-channel frame filtering in mac80211 by moving the software scanning off-channel drop check from early TX handling (ieee80211_tx_h_check_assoc and ieee80211_8023_xmit) into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked in invoke_tx_handlers_late().\n\nThis change only affects internal control flow and packet drop decisions during TX processing on existing, initialized skb headers and state bitmaps. It does not introduce or modify any data allocations, structure copying to user space, uninitialized variable accesses, or buffer boundary calculations. Standard KASAN fuzzing is sufficient to cover any packet handling or lifecycle issues, and a dedicated KMSAN fuzzing session is not warranted.",
"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 6b7cd5bcc482deb802b89227fc840fa9b6981b02
Author: syz-cluster <triage@syzkaller.com>
Date: Mon Sep 7 14:47:41 2026 +0000
syz-cluster: applied patch under review
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91b14112e24f0..08a39272f26a0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -269,7 +269,6 @@ ieee80211_tx_h_dynamic_ps(struct ieee80211_tx_data *tx)
static ieee80211_tx_result debug_noinline
ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
{
-
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
bool assoc = false;
@@ -277,20 +276,6 @@ ieee80211_tx_h_check_assoc(struct ieee80211_tx_data *tx)
if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED))
return TX_CONTINUE;
- if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) &&
- test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) &&
- !ieee80211_is_probe_req(hdr->frame_control) &&
- !ieee80211_is_any_nullfunc(hdr->frame_control))
- /*
- * When software scanning only nullfunc frames (to notify
- * the sleep state to the AP) and probe requests (for the
- * active scan) are allowed, all other frames should not be
- * sent and we should not get here, but if we do
- * nonetheless, drop them to avoid sending them
- * off-channel. See __ieee80211_start_scan() for more.
- */
- return TX_DROP;
-
if (tx->sdata->vif.type == NL80211_IFTYPE_OCB)
return TX_CONTINUE;
@@ -805,6 +790,33 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
return TX_CONTINUE;
}
+static ieee80211_tx_result debug_noinline
+ieee80211_tx_h_check_offchannel(struct ieee80211_tx_data *tx)
+{
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
+
+ if (unlikely(info->flags & IEEE80211_TX_CTL_INJECTED))
+ return TX_CONTINUE;
+
+ if (unlikely(test_bit(SCAN_SW_SCANNING, &tx->local->scanning)) &&
+ test_bit(SDATA_STATE_OFFCHANNEL, &tx->sdata->state) &&
+ !ieee80211_is_probe_req(hdr->frame_control) &&
+ !ieee80211_is_any_nullfunc(hdr->frame_control)) {
+ /*
+ * When software scanning only nullfunc frames (to notify
+ * the sleep state to the AP) and probe requests (for the
+ * active scan) are allowed, all other frames should not be
+ * sent and we should not get here, but if we do
+ * nonetheless, drop them to avoid sending them
+ * off-channel. See __ieee80211_start_scan() for more.
+ */
+ return TX_DROP;
+ }
+
+ return TX_CONTINUE;
+}
+
static __le16 ieee80211_tx_next_seq(struct sta_info *sta, int tid)
{
u16 *seq = &sta->tid_seq[tid];
@@ -1864,6 +1876,7 @@ static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)
goto txh_done;
}
+ CALL_TXH(ieee80211_tx_h_check_offchannel);
CALL_TXH(ieee80211_tx_h_michael_mic_add);
CALL_TXH(ieee80211_tx_h_sequence);
CALL_TXH(ieee80211_tx_h_fragment);
@@ -4686,10 +4699,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
queue = ieee80211_select_queue(sdata, sta, skb);
skb_set_queue_mapping(skb, queue);
- if (unlikely(test_bit(SCAN_SW_SCANNING, &local->scanning)) &&
- test_bit(SDATA_STATE_OFFCHANNEL, &sdata->state))
- goto out_free;
-
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return;
@@ -4756,11 +4765,6 @@ static void ieee80211_8023_xmit(struct ieee80211_sub_if_data *sdata,
ieee80211_tpt_led_trig_tx(local, len);
ieee80211_tx_8023(sdata, skb, sta, false);
-
- return;
-
-out_free:
- kfree_skb(skb);
}
static bool ieee80211_check_mcast_offload(struct ieee80211_sub_if_data *sdata,
|
| 25/3 | 2026/09/07 14:48 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 3529 output: 36 thoughts: 410 Thoughts: **Assessing Uninitialized Memory Risks in a Wireless Patch** Okay, let's break this down. My goal is to determine if this patch introduces any new risks of uninitialized memory usage that would justify a dedicated KMSAN fuzzing session. This is standard procedure for changes touching networking code, especially when dealing with potentially complex packet processing. First, I'm seeing changes in `net/mac80211/tx.c`. The core seems to be about how the driver handles off-channel scanning within the transmission path. Specifically: 1. The off-channel scanning check in `ieee80211_tx_h_check_assoc` has been *removed*. This is concerning, because it's been moved. Anytime a check is removed, I need to know why. Are we losing a check? Is the functionality still present? I need to understand if this is a control flow change. 2. A new handler, `ieee80211_tx_h_check_offchannel`, has been *created* and is being called later in the transmission process via `invoke_tx_handlers_late()`. This is interesting; it's a refactoring, but a refactoring that *could* introduce subtle timing differences or code path changes. 3. The early check in `ieee80211_8023_xmit` regarding off-channel scanning has also been *removed*. This mirrors the change in the previous function, so it's a related code path. So, it looks like the guard is still in place, it has been moved to a late stage handler, but I need to understand why this was done and make sure that the function is still guarding the code paths appropriately. Now, I need to know the *why*. Was this purely for code clarity? Performance? Or is there a functional change lurking here? I'm going to leverage `grepper` or `read-file` to search for more context on these changes. I'll be looking for explanations for the original decision to move the function. I'll look for bug reports, mailing list discussions, commit messages, and related code changes to fully understand the rationale and impact of this change. From there, I'll be able to tell if these changes are sound, and if they may expose uninitialized memory. |
| 26/3 | 2026/09/07 14:48 | tool | grepper |
0mArgs:{
"Expression": "invoke_tx_handlers_late",
"PathPrefix": "net/mac80211/"
}Results: {
"Output": "net/mac80211/tx.c=1828=static int invoke_tx_handlers_early(struct ieee80211_tx_data *tx)\n--\nnet/mac80211/tx.c-1864- */\nnet/mac80211/tx.c:1865:static int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)\nnet/mac80211/tx.c-1866-{\n--\nnet/mac80211/tx.c=1906=static int invoke_tx_handlers(struct ieee80211_tx_data *tx)\n--\nnet/mac80211/tx.c-1911-\t\treturn r;\nnet/mac80211/tx.c:1912:\treturn invoke_tx_handlers_late(tx);\nnet/mac80211/tx.c-1913-}\n--\nnet/mac80211/tx.c=1958=static bool ieee80211_tx(struct ieee80211_sub_if_data *sdata,\n--\nnet/mac80211/tx.c-1995-\nnet/mac80211/tx.c:1996:\tif (!invoke_tx_handlers_late(\u0026tx))\nnet/mac80211/tx.c-1997-\t\tresult = __ieee80211_tx(local, \u0026tx.skbs, tx.sta, txpending);\n--\nnet/mac80211/tx.c=3888=struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,\n--\nnet/mac80211/tx.c-4015-\t} else {\nnet/mac80211/tx.c:4016:\t\tif (invoke_tx_handlers_late(\u0026tx))\nnet/mac80211/tx.c-4017-\t\t\tgoto begin;\n"
} |
| 27/3 | 2026/09/07 14:48 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 5016 output: 41 thoughts: 22 Thoughts: Here's my take on those lines in `tx.c`: **Diving Deep into `tx.c`'s Core** Okay, so I need to understand what's happening within `tx.c` between lines 1850 and 1920. That's a decent chunk of code, likely handling a crucial aspect of the transaction processing pipeline. I'm going to start by getting a high-level view of the surrounding context. What functions or data structures are being called just before and after this section? I'll probably need to understand the purpose of `tx.c` to properly orient myself. Is this related to transaction validation, signing, broadcasting, or something else entirely? My first pass will be to identify any major control flow statements like `if`, `for`, or `switch` statements. That will give me a sense of the logic flow. Next, I'll pay close attention to any function calls within that range. Are there any calls to other modules or custom-defined functions? Those are likely where the heavy lifting, or any specialized logic, is happening. Are there any interactions with external systems? Are any data structures being used within this particular range that I need to be familiar with? Understanding how the data flows in and out of those functions will be essential. Any resource allocation or deallocation jumps out as an immediate potential issue that needs to be scrutinized. I anticipate seeing a lot of bitwise operations, especially if this is related to hashing, serialization, or consensus mechanisms. I'll need to double-check my understanding of any libraries or external dependencies used. Finally, I'll look for any potential areas for optimization, or potential bottlenecks. This section seems potentially involved with transactions, so I'll be alert for anything that might impact throughput, latency, or security. |
| 28/3 | 2026/09/07 14:48 | tool | read-file |
0mArgs:{
"File": "net/mac80211/tx.c",
"FirstLine": 1850,
"LineCount": 80
}Results: {
"Contents": "1850:\t\t\telse\n1851:\t\t\t\tieee80211_purge_tx_queue(\u0026tx-\u003elocal-\u003ehw, \u0026tx-\u003eskbs);\n1852:\t\t\treturn -1;\n1853:\t\t} else if (unlikely(res == TX_QUEUED)) {\n1854:\t\t\tI802_DEBUG_INC(tx-\u003elocal-\u003etx_handlers_queued);\n1855:\t\t\treturn -1;\n1856:\t\t}\n1857:\t\n1858:\t\treturn 0;\n1859:\t}\n1860:\t\n1861:\t/*\n1862:\t * Late handlers can be called while the sta lock is held. Handlers that can\n1863:\t * cause packets to be generated will cause deadlock!\n1864:\t */\n1865:\tstatic int invoke_tx_handlers_late(struct ieee80211_tx_data *tx)\n1866:\t{\n1867:\t\tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx-\u003eskb);\n1868:\t\tieee80211_tx_result res = TX_CONTINUE;\n1869:\t\n1870:\t\tif (!ieee80211_hw_check(\u0026tx-\u003elocal-\u003ehw, HAS_RATE_CONTROL))\n1871:\t\t\tCALL_TXH(ieee80211_tx_h_rate_ctrl);\n1872:\t\n1873:\t\tif (unlikely(info-\u003eflags \u0026 IEEE80211_TX_INTFL_RETRANSMISSION)) {\n1874:\t\t\t__skb_queue_tail(\u0026tx-\u003eskbs, tx-\u003eskb);\n1875:\t\t\ttx-\u003eskb = NULL;\n1876:\t\t\tgoto txh_done;\n1877:\t\t}\n1878:\t\n1879:\t\tCALL_TXH(ieee80211_tx_h_check_offchannel);\n1880:\t\tCALL_TXH(ieee80211_tx_h_michael_mic_add);\n1881:\t\tCALL_TXH(ieee80211_tx_h_sequence);\n1882:\t\tCALL_TXH(ieee80211_tx_h_fragment);\n1883:\t\t/* handlers after fragment must be aware of tx info fragmentation! */\n1884:\t\tCALL_TXH(ieee80211_tx_h_stats);\n1885:\t\tCALL_TXH(ieee80211_tx_h_encrypt);\n1886:\t\tif (!ieee80211_hw_check(\u0026tx-\u003elocal-\u003ehw, HAS_RATE_CONTROL))\n1887:\t\t\tCALL_TXH(ieee80211_tx_h_calculate_duration);\n1888:\t#undef CALL_TXH\n1889:\t\n1890:\t txh_done:\n1891:\t\tif (unlikely(res == TX_DROP)) {\n1892:\t\t\ttx-\u003esdata-\u003etx_handlers_drop++;\n1893:\t\t\tif (tx-\u003eskb)\n1894:\t\t\t\tieee80211_free_txskb(\u0026tx-\u003elocal-\u003ehw, tx-\u003eskb);\n1895:\t\t\telse\n1896:\t\t\t\tieee80211_purge_tx_queue(\u0026tx-\u003elocal-\u003ehw, \u0026tx-\u003eskbs);\n1897:\t\t\treturn -1;\n1898:\t\t} else if (unlikely(res == TX_QUEUED)) {\n1899:\t\t\tI802_DEBUG_INC(tx-\u003elocal-\u003etx_handlers_queued);\n1900:\t\t\treturn -1;\n1901:\t\t}\n1902:\t\n1903:\t\treturn 0;\n1904:\t}\n1905:\t\n1906:\tstatic int invoke_tx_handlers(struct ieee80211_tx_data *tx)\n1907:\t{\n1908:\t\tint r = invoke_tx_handlers_early(tx);\n1909:\t\n1910:\t\tif (r)\n1911:\t\t\treturn r;\n1912:\t\treturn invoke_tx_handlers_late(tx);\n1913:\t}\n1914:\t\n1915:\tbool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,\n1916:\t\t\t\t struct ieee80211_vif *vif, struct sk_buff *skb,\n1917:\t\t\t\t int band, struct ieee80211_sta **sta)\n1918:\t{\n1919:\t\tstruct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);\n1920:\t\tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);\n1921:\t\tstruct ieee80211_tx_data tx;\n1922:\t\tstruct sk_buff *skb2;\n1923:\t\n1924:\t\tif (ieee80211_tx_prepare(sdata, \u0026tx, NULL, skb) == TX_DROP) {\n1925:\t\t\tkfree_skb(skb);\n1926:\t\t\treturn false;\n1927:\t\t}\n1928:\t\n1929:\t\tinfo-\u003eband = band;\n"
} |
| 29/3 | 2026/09/07 14:48 | llm | kmsan-evaluator |
0mModel:gemini-3.7-flash Args: null Results: null Tokens: input: 6897 output: 204 thoughts: 749 Thoughts: **Analyzing the Patch for Potential KMSAN Implications** Okay, let's break this down. My initial focus is on the impact of this patch and whether it introduces any risks that KMSAN would need to flag. My understanding is that we're moving the off-channel check for TX packets within mac80211, specifically from the early transmit handlers (`ieee80211_tx_h_check_assoc` called in `invoke_tx_handlers_early`) and the 802.3 transmit path (`ieee80211_8023_xmit`) to the *late* transmit handler pipeline, specifically `ieee80211_tx_h_check_offchannel` within `invoke_tx_handlers_late`. My first immediate question: does this involve any new allocations or changes to user-space interactions that could potentially expose uninitialized memory? Going through the usual checklist: 1. **User-Space Interaction:** No, this patch doesn't modify any kernel structures passed to userspace via `copy_to_user`, netlink, ioctl, sockets, or BPF buffers. No uninitialized fields are being exposed. 2. **Conditional Logic:** No. The patch doesn't introduce any new conditional logic or branching that relies on uninitialized variables. It's reading existing struct fields like `tx->local->scanning`, `tx->sdata->state`, `hdr->frame_control`, and `info->flags` - all of which should be initialized. 3. **Data Structure Initialization:** I see no new data structure allocations or complex initializations where an uninitialized field might cause issues later. 4. **Bounds Checks/Length Changes:** No modifications that would allow the surrounding code to access uninitialized bytes. So, from what I can tell, there's no inherent risk of introducing uninitialized memory reads or leaks. This is purely a refactoring of *when* the off-channel check happens, not *how* the data is handled. My understanding of KMSAN is that it's designed to detect reads of uninitialized memory and kernel-to-user info leaks. KASAN/other sanitizers cover memory corruption, UAF, OOB, etc., which this isn't touching. This patch deals with moving the filter. It operates on *fully initialized* SKB control buffers and headers. Therefore, from my perspective, the `NeedsKMSAN` flag is `false`. The reasoning is clear: the patch is a refactor of the off-channel scanning check in mac80211, moving the location but not altering the core data structures or introducing any memory safety vulnerabilities that would trigger KMSAN. KASAN/other sanitizers should be sufficient. |
| 30/3 | 2026/09/07 14:49 | tool | set-results |
0mArgs:{
"KMSANReasoning": "The patch refactors off-channel frame filtering in mac80211 by moving the software scanning off-channel drop check from early TX handling (ieee80211_tx_h_check_assoc and ieee80211_8023_xmit) into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked in invoke_tx_handlers_late().\n\nThis change only affects internal control flow and packet drop decisions during TX processing on existing, initialized skb headers and state bitmaps. It does not introduce or modify any data allocations, structure copying to user space, uninitialized variable accesses, or buffer boundary calculations. Standard KASAN fuzzing is sufficient to cover any packet handling or lifecycle issues, and a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
}Results: {
"KMSANReasoning": "The patch refactors off-channel frame filtering in mac80211 by moving the software scanning off-channel drop check from early TX handling (ieee80211_tx_h_check_assoc and ieee80211_8023_xmit) into a dedicated late TX handler (ieee80211_tx_h_check_offchannel) invoked in invoke_tx_handlers_late().\n\nThis change only affects internal control flow and packet drop decisions during TX processing on existing, initialized skb headers and state bitmaps. It does not introduce or modify any data allocations, structure copying to user space, uninitialized variable accesses, or buffer boundary calculations. Standard KASAN fuzzing is sufficient to cover any packet handling or lifecycle issues, and a dedicated KMSAN fuzzing session is not warranted.",
"NeedsKMSAN": false
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|