AI Trajectory

null

{
  "EnableConfigs": [
    "MAC80211",
    "MAC80211_HWSIM",
    "CFG80211"
  ],
  "FocusSymbols": [
    "ieee80211_parse_tx_radiotap",
    "ieee80211_monitor_start_xmit"
  ],
  "KMSANReasoning": "The patch fixes a logic bug where `skb_trim` was incorrectly called during `ieee80211_monitor_select_queue` when parsing the radiotap header. Trimming the FCS trailer at this stage reduced `skb-\u003elen`, causing the subsequent call to `ieee80211_parse_tx_radiotap` in `ieee80211_monitor_start_xmit` to fail its length check (`skb-\u003elen \u003c (iterator._max_length + FCS_LEN)`) and drop the packet. The fix introduces a `trim_fcs` boolean to defer the trimming until `ieee80211_monitor_start_xmit`.\n\nThis is a logic bug related to packet length manipulation and does not involve uninitialized memory allocations, accesses, or info-leaks. Standard KASAN and other bug detectors are sufficient for catching memory corruption or out-of-bounds issues in this area. A dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch modifies `ieee80211_parse_tx_radiotap` to optionally trim the FCS trailer from injected packets. This function is reachable when injecting packets into a mac80211 monitor interface, which can be tested using the mac80211_hwsim driver. This is a functional change in the core mac80211 networking stack.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit f088809e9cee102d9b350759d31ddad04d40a83b\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Tue Aug 18 00:28:57 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/include/net/mac80211.h b/include/net/mac80211.h\nindex 4f95da023746f..0becd3361010f 100644\n--- a/include/net/mac80211.h\n+++ b/include/net/mac80211.h\n@@ -7615,11 +7615,12 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,\n  *\n  * @skb: packet injected by userspace\n  * @dev: the \u0026struct device of this 802.11 device\n+ * @trim_fcs: trim the FCS trailer when present; validate it otherwise\n  *\n  * Return: %true if the radiotap header was parsed, %false otherwise\n  */\n bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\n-\t\t\t\t struct net_device *dev);\n+\t\t\t\t struct net_device *dev, bool trim_fcs);\n \n /**\n  * struct ieee80211_noa_data - holds temporary data for tracking P2P NoA state\ndiff --git a/net/mac80211/iface.c b/net/mac80211/iface.c\nindex 43460a705a6bd..fdac729ca580d 100644\n--- a/net/mac80211/iface.c\n+++ b/net/mac80211/iface.c\n@@ -964,7 +964,7 @@ static u16 ieee80211_monitor_select_queue(struct net_device *dev,\n \t/* reset flags and info before parsing radiotap header */\n \tmemset(info, 0, sizeof(*info));\n \n-\tif (!ieee80211_parse_tx_radiotap(skb, dev))\n+\tif (!ieee80211_parse_tx_radiotap(skb, dev, false))\n \t\treturn 0; /* doesn't matter, frame will be dropped */\n \n \tlen_rthdr = ieee80211_get_radiotap_len(skb-\u003edata);\ndiff --git a/net/mac80211/tx.c b/net/mac80211/tx.c\nindex 91b14112e24f0..97990039695db 100644\n--- a/net/mac80211/tx.c\n+++ b/net/mac80211/tx.c\n@@ -2097,7 +2097,7 @@ static bool ieee80211_validate_radiotap_len(struct sk_buff *skb)\n }\n \n bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\n-\t\t\t\t struct net_device *dev)\n+\t\t\t\t struct net_device *dev, bool trim_fcs)\n {\n \tstruct ieee80211_local *local = wdev_priv(dev-\u003eieee80211_ptr);\n \tstruct ieee80211_radiotap_iterator iterator;\n@@ -2154,7 +2154,8 @@ bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\n \t\t\t\tif (skb-\u003elen \u003c (iterator._max_length + FCS_LEN))\n \t\t\t\t\treturn false;\n \n-\t\t\t\tskb_trim(skb, skb-\u003elen - FCS_LEN);\n+\t\t\t\tif (trim_fcs)\n+\t\t\t\t\tskb_trim(skb, skb-\u003elen - FCS_LEN);\n \t\t\t}\n \t\t\tif (*iterator.this_arg \u0026 IEEE80211_RADIOTAP_F_WEP)\n \t\t\t\tinfo-\u003eflags \u0026= ~IEEE80211_TX_INTFL_DONT_ENCRYPT;\n@@ -2470,7 +2471,7 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,\n \t * selected chandef above to accurately set injection rates and\n \t * retransmissions.\n \t */\n-\tif (!ieee80211_parse_tx_radiotap(skb, dev))\n+\tif (!ieee80211_parse_tx_radiotap(skb, dev, true))\n \t\tgoto fail_rcu;\n \n \t/* remove the injection radiotap header */\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "MAC80211",
    "MAC80211_HWSIM",
    "CFG80211"
  ],
  "FocusSymbols": [
    "ieee80211_parse_tx_radiotap",
    "ieee80211_monitor_start_xmit"
  ],
  "Reasoning": "The patch modifies `ieee80211_parse_tx_radiotap` to optionally trim the FCS trailer from injected packets. This function is reachable when injecting packets into a mac80211 monitor interface, which can be tested using the mac80211_hwsim driver. This is a functional change in the core mac80211 networking stack.",
  "WorthFuzzing": true
}

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

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

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

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

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


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

For your convenience, here is the diff of the changes:
commit f088809e9cee102d9b350759d31ddad04d40a83b
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 00:28:57 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4f95da023746f..0becd3361010f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -7615,11 +7615,12 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
  *
  * @skb: packet injected by userspace
  * @dev: the &struct device of this 802.11 device
+ * @trim_fcs: trim the FCS trailer when present; validate it otherwise
  *
  * Return: %true if the radiotap header was parsed, %false otherwise
  */
 bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
-				 struct net_device *dev);
+				 struct net_device *dev, bool trim_fcs);
 
 /**
  * struct ieee80211_noa_data - holds temporary data for tracking P2P NoA state
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 43460a705a6bd..fdac729ca580d 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -964,7 +964,7 @@ static u16 ieee80211_monitor_select_queue(struct net_device *dev,
 	/* reset flags and info before parsing radiotap header */
 	memset(info, 0, sizeof(*info));
 
-	if (!ieee80211_parse_tx_radiotap(skb, dev))
+	if (!ieee80211_parse_tx_radiotap(skb, dev, false))
 		return 0; /* doesn't matter, frame will be dropped */
 
 	len_rthdr = ieee80211_get_radiotap_len(skb->data);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91b14112e24f0..97990039695db 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2097,7 +2097,7 @@ static bool ieee80211_validate_radiotap_len(struct sk_buff *skb)
 }
 
 bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
-				 struct net_device *dev)
+				 struct net_device *dev, bool trim_fcs)
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
 	struct ieee80211_radiotap_iterator iterator;
@@ -2154,7 +2154,8 @@ bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
 				if (skb->len < (iterator._max_length + FCS_LEN))
 					return false;
 
-				skb_trim(skb, skb->len - FCS_LEN);
+				if (trim_fcs)
+					skb_trim(skb, skb->len - FCS_LEN);
 			}
 			if (*iterator.this_arg & IEEE80211_RADIOTAP_F_WEP)
 				info->flags &= ~IEEE80211_TX_INTFL_DONT_ENCRYPT;
@@ -2470,7 +2471,7 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 	 * selected chandef above to accurately set injection rates and
 	 * retransmissions.
 	 */
-	if (!ieee80211_parse_tx_radiotap(skb, dev))
+	if (!ieee80211_parse_tx_radiotap(skb, dev, true))
 		goto fail_rcu;
 
 	/* remove the injection radiotap header */

gemini-3.1-pro-preview

null

null

							input: 2943
							output: 38
							thoughts: 310
						

**My Assessment of the mac80211 Patch**

Okay, so I've got this patch that tweaks `ieee80211_parse_tx_radiotap` in `net/mac80211/tx.c` and `net/mac80211/iface.c`. It's adding a `trim_fcs` boolean to that function, which means we can now optionally strip the Frame Check Sequence (FCS) trailer. That's a functional change within mac80211, which is, of course, the heart of the 802.11 implementation in the kernel. This is definitely something we can fuzz using `mac80211_hwsim`, which makes this interesting.

My next step is to examine the function's callers to understand the impact of this change. Let's see... the code shows that `ieee80211_monitor_select_queue` in `net/mac80211/iface.c` and `ieee80211_monitor_start_xmit` in `net/mac80211/tx.c` call it. Now, those are both interesting call sites. I need to understand how they’re using the radiotap data, and how this `trim_fcs` might affect them. I'll need to dig into the context of those functions to see how they'll handle the FCS trimming and if this introduces any subtle bugs.

Finally, I need to confirm the relevant configuration options. `CONFIG_MAC80211` is usually the one, but I need to make sure that's correct for this particular build configuration.

{
  "Expression": "config MAC80211",
  "PathPrefix": "net/mac80211/Kconfig"
}

{
  "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--\nnet/mac80211/Kconfig=19=if MAC80211 != n\nnet/mac80211/Kconfig-20-\nnet/mac80211/Kconfig:21:config MAC80211_HAS_RC\nnet/mac80211/Kconfig-22-\tbool\nnet/mac80211/Kconfig-23-\nnet/mac80211/Kconfig:24:config MAC80211_RC_MINSTREL\nnet/mac80211/Kconfig-25-\tbool \"Minstrel\" if EXPERT\n--\nnet/mac80211/Kconfig=31=choice\n--\nnet/mac80211/Kconfig-40-\nnet/mac80211/Kconfig:41:config MAC80211_RC_DEFAULT_MINSTREL\nnet/mac80211/Kconfig-42-\tbool \"Minstrel\"\n--\nnet/mac80211/Kconfig=48=endchoice\nnet/mac80211/Kconfig-49-\nnet/mac80211/Kconfig:50:config MAC80211_RC_DEFAULT\nnet/mac80211/Kconfig-51-\tstring\n--\nnet/mac80211/Kconfig=57=comment \"Some wireless drivers require a rate control algorithm\"\n--\nnet/mac80211/Kconfig-59-\nnet/mac80211/Kconfig:60:config MAC80211_KUNIT_TEST\nnet/mac80211/Kconfig-61-\ttristate \"KUnit tests for mac80211\" if !KUNIT_ALL_TESTS\n--\nnet/mac80211/Kconfig-69-\nnet/mac80211/Kconfig:70:config MAC80211_MESH\nnet/mac80211/Kconfig-71-\tbool \"Enable mac80211 mesh networking support\"\n--\nnet/mac80211/Kconfig-78-\nnet/mac80211/Kconfig:79:config MAC80211_LEDS\nnet/mac80211/Kconfig-80-\tbool \"Enable LED triggers\"\n--\nnet/mac80211/Kconfig-87-\nnet/mac80211/Kconfig:88:config MAC80211_DEBUGFS\nnet/mac80211/Kconfig-89-\tbool \"Export mac80211 internals in DebugFS\"\n--\nnet/mac80211/Kconfig-96-\nnet/mac80211/Kconfig:97:config MAC80211_MESSAGE_TRACING\nnet/mac80211/Kconfig-98-\tbool \"Trace all mac80211 debug messages\"\n--\nnet/mac80211/Kconfig-109-\nnet/mac80211/Kconfig:110:menuconfig MAC80211_DEBUG_MENU\nnet/mac80211/Kconfig-111-\tbool \"Select mac80211 debugging features\"\n--\nnet/mac80211/Kconfig-115-\nnet/mac80211/Kconfig:116:config MAC80211_NOINLINE\nnet/mac80211/Kconfig-117-\tbool \"Do not inline TX/RX handlers\"\n--\nnet/mac80211/Kconfig-131-\nnet/mac80211/Kconfig:132:config MAC80211_VERBOSE_DEBUG\nnet/mac80211/Kconfig-133-\tbool \"Verbose debugging output\"\n--\nnet/mac80211/Kconfig-142-\nnet/mac80211/Kconfig:143:config MAC80211_MLME_DEBUG\nnet/mac80211/Kconfig-144-\tbool \"Verbose managed MLME output\"\n--\nnet/mac80211/Kconfig-153-\nnet/mac80211/Kconfig:154:config MAC80211_STA_DEBUG\nnet/mac80211/Kconfig-155-\tbool \"Verbose station debugging\"\n--\nnet/mac80211/Kconfig-162-\nnet/mac80211/Kconfig:163:config MAC80211_HT_DEBUG\nnet/mac80211/Kconfig-164-\tbool \"Verbose HT debugging\"\n--\nnet/mac80211/Kconfig-174-\nnet/mac80211/Kconfig:175:config MAC80211_OCB_DEBUG\nnet/mac80211/Kconfig-176-\tbool \"Verbose OCB debugging\"\n--\nnet/mac80211/Kconfig-185-\nnet/mac80211/Kconfig:186:config MAC80211_IBSS_DEBUG\nnet/mac80211/Kconfig-187-\tbool \"Verbose IBSS debugging\"\n--\nnet/mac80211/Kconfig-196-\nnet/mac80211/Kconfig:197:config MAC80211_PS_DEBUG\nnet/mac80211/Kconfig-198-\tbool \"Verbose powersave mode debugging\"\n--\nnet/mac80211/Kconfig-208-\nnet/mac80211/Kconfig:209:config MAC80211_MPL_DEBUG\nnet/mac80211/Kconfig-210-\tbool \"Verbose mesh peer link debugging\"\n--\nnet/mac80211/Kconfig-221-\nnet/mac80211/Kconfig:222:config MAC80211_MPATH_DEBUG\nnet/mac80211/Kconfig-223-\tbool \"Verbose mesh path debugging\"\n--\nnet/mac80211/Kconfig-234-\nnet/mac80211/Kconfig:235:config MAC80211_MHWMP_DEBUG\nnet/mac80211/Kconfig-236-\tbool \"Verbose mesh HWMP routing debugging\"\n--\nnet/mac80211/Kconfig-247-\nnet/mac80211/Kconfig:248:config MAC80211_MESH_SYNC_DEBUG\nnet/mac80211/Kconfig-249-\tbool \"Verbose mesh synchronization debugging\"\n--\nnet/mac80211/Kconfig-258-\nnet/mac80211/Kconfig:259:config MAC80211_MESH_CSA_DEBUG\nnet/mac80211/Kconfig-260-\tbool \"Verbose mesh channel switch debugging\"\n--\nnet/mac80211/Kconfig-269-\nnet/mac80211/Kconfig:270:config MAC80211_MESH_PS_DEBUG\nnet/mac80211/Kconfig-271-\tbool \"Verbose mesh powersave debugging\"\n--\nnet/mac80211/Kconfig-280-\nnet/mac80211/Kconfig:281:config MAC80211_TDLS_DEBUG\nnet/mac80211/Kconfig-282-\tbool \"Verbose TDLS debugging\"\n--\nnet/mac80211/Kconfig-292-\nnet/mac80211/Kconfig:293:config MAC80211_DEBUG_COUNTERS\nnet/mac80211/Kconfig-294-\tbool \"Extra statistics for TX/RX debugging\"\n--\nnet/mac80211/Kconfig-307-\nnet/mac80211/Kconfig:308:config MAC80211_STA_HASH_MAX_SIZE\nnet/mac80211/Kconfig-309-\tint \"Station hash table maximum size\" if MAC80211_DEBUG_MENU\n"
}

gemini-3.1-pro-preview

null

null

							input: 5844
							output: 49
							thoughts: 32
						

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

**Analyzing the MAC80211 Configuration**

Right, so we're dealing with a `MAC80211` configuration. Standard stuff. My immediate thought is, "Okay, where are we heading with this?" The natural next question is always, *do we need* `MAC80211_HWSIM`? The implication is that we want to ensure hardware simulation is appropriately handled, or disabled where not needed. We are looking to reduce complexity of the build and ensure that any hardware specific dependencies are included when appropriate.

no matches

{
  "Expression": "config MAC80211_HWSIM",
  "PathPrefix": "drivers/net/wireless/mac80211_hwsim/Kconfig"
}

{
  "error": "no matches"
}

gemini-3.1-pro-preview

null

null

							input: 6073
							output: 37
							thoughts: 27
						

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

**Diving into the Wireless Driver Landscape**

Right, let's get down to brass tacks. I'm thinking I need to find the specific kernel code related to the MAC80211 hardware simulator, `MAC80211_HWSIM`. I know I've worked with it before, but the exact location in the Linux kernel source tree always slips my mind. No problem, time to do a quick search. The wireless networking drivers are usually organized under `drivers/net/wireless`, so that's where I'll start looking. I'll need to refresh my memory on the interactions of that particular module. Time to get my hands dirty and track down this piece of code.

{
  "Expression": "config MAC80211_HWSIM",
  "PathPrefix": "drivers/net/wireless/"
}

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

gemini-3.1-pro-preview

null

null

							input: 6374
							output: 42
							thoughts: 83
						

Okay, let's break this down.

**Diving into the MAC80211 HWSIM Configuration and Radiotap Parsing**

Right, so I'm looking at the `MAC80211_HWSIM` configuration. That tells me this is all about the hardware simulator, which is key to my work. I need to understand how the system is behaving under simulated conditions. Now, the crucial part I need to get a handle on is how the transmit radiotap headers are being handled, so I need to understand what modifications have been made to the system for the simulator. I know that the function `ieee80211_parse_tx_radiotap` is the key. My focus is on that parsing function. So, I need to open `net/mac80211/tx.c` and have a good look at that function. I need to trace through it, paying particular attention to how the radiotap information is interpreted within the HWSIM context. I'm looking for where things deviate or interact with the simulated environment.

{
  "File": "net/mac80211/tx.c",
  "FirstLine": 2096,
  "LineCount": 100
}

{
  "Contents": "2096:\t\treturn true;\n2097:\t}\n2098:\t\n2099:\tbool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\n2100:\t\t\t\t\t struct net_device *dev, bool trim_fcs)\n2101:\t{\n2102:\t\tstruct ieee80211_local *local = wdev_priv(dev-\u003eieee80211_ptr);\n2103:\t\tstruct ieee80211_radiotap_iterator iterator;\n2104:\t\tstruct ieee80211_radiotap_header *rthdr =\n2105:\t\t\t(struct ieee80211_radiotap_header *) skb-\u003edata;\n2106:\t\tstruct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);\n2107:\t\tint ret = ieee80211_radiotap_iterator_init(\u0026iterator, rthdr, skb-\u003elen,\n2108:\t\t\t\t\t\t\t   NULL);\n2109:\t\tu16 txflags;\n2110:\t\tu16 rate = 0;\n2111:\t\tbool rate_found = false;\n2112:\t\tu8 rate_retries = 0;\n2113:\t\tu16 rate_flags = 0;\n2114:\t\tu8 mcs_known, mcs_flags, mcs_bw;\n2115:\t\tu16 vht_known;\n2116:\t\tu8 vht_mcs = 0, vht_nss = 0;\n2117:\t\tint i;\n2118:\t\n2119:\t\tif (!ieee80211_validate_radiotap_len(skb))\n2120:\t\t\treturn false;\n2121:\t\n2122:\t\tinfo-\u003eflags |= IEEE80211_TX_INTFL_DONT_ENCRYPT |\n2123:\t\t\t       IEEE80211_TX_CTL_DONTFRAG;\n2124:\t\n2125:\t\t/*\n2126:\t\t * for every radiotap entry that is present\n2127:\t\t * (ieee80211_radiotap_iterator_next returns -ENOENT when no more\n2128:\t\t * entries present, or -EINVAL on error)\n2129:\t\t */\n2130:\t\n2131:\t\twhile (!ret) {\n2132:\t\t\tret = ieee80211_radiotap_iterator_next(\u0026iterator);\n2133:\t\n2134:\t\t\tif (ret)\n2135:\t\t\t\tcontinue;\n2136:\t\n2137:\t\t\t/* see if this argument is something we can use */\n2138:\t\t\tswitch (iterator.this_arg_index) {\n2139:\t\t\t/*\n2140:\t\t\t * You must take care when dereferencing iterator.this_arg\n2141:\t\t\t * for multibyte types... the pointer is not aligned.  Use\n2142:\t\t\t * get_unaligned((type *)iterator.this_arg) to dereference\n2143:\t\t\t * iterator.this_arg for type \"type\" safely on all arches.\n2144:\t\t\t*/\n2145:\t\t\tcase IEEE80211_RADIOTAP_FLAGS:\n2146:\t\t\t\tif (*iterator.this_arg \u0026 IEEE80211_RADIOTAP_F_FCS) {\n2147:\t\t\t\t\t/*\n2148:\t\t\t\t\t * this indicates that the skb we have been\n2149:\t\t\t\t\t * handed has the 32-bit FCS CRC at the end...\n2150:\t\t\t\t\t * we should react to that by snipping it off\n2151:\t\t\t\t\t * because it will be recomputed and added\n2152:\t\t\t\t\t * on transmission\n2153:\t\t\t\t\t */\n2154:\t\t\t\t\tif (skb-\u003elen \u003c (iterator._max_length + FCS_LEN))\n2155:\t\t\t\t\t\treturn false;\n2156:\t\n2157:\t\t\t\t\tif (trim_fcs)\n2158:\t\t\t\t\t\tskb_trim(skb, skb-\u003elen - FCS_LEN);\n2159:\t\t\t\t}\n2160:\t\t\t\tif (*iterator.this_arg \u0026 IEEE80211_RADIOTAP_F_WEP)\n2161:\t\t\t\t\tinfo-\u003eflags \u0026= ~IEEE80211_TX_INTFL_DONT_ENCRYPT;\n2162:\t\t\t\tif (*iterator.this_arg \u0026 IEEE80211_RADIOTAP_F_FRAG)\n2163:\t\t\t\t\tinfo-\u003eflags \u0026= ~IEEE80211_TX_CTL_DONTFRAG;\n2164:\t\t\t\tbreak;\n2165:\t\n2166:\t\t\tcase IEEE80211_RADIOTAP_TX_FLAGS:\n2167:\t\t\t\ttxflags = get_unaligned_le16(iterator.this_arg);\n2168:\t\t\t\tif (txflags \u0026 IEEE80211_RADIOTAP_F_TX_NOACK)\n2169:\t\t\t\t\tinfo-\u003eflags |= IEEE80211_TX_CTL_NO_ACK;\n2170:\t\t\t\tif (txflags \u0026 IEEE80211_RADIOTAP_F_TX_NOSEQNO)\n2171:\t\t\t\t\tinfo-\u003econtrol.flags |= IEEE80211_TX_CTRL_NO_SEQNO;\n2172:\t\t\t\tif (txflags \u0026 IEEE80211_RADIOTAP_F_TX_ORDER)\n2173:\t\t\t\t\tinfo-\u003econtrol.flags |=\n2174:\t\t\t\t\t\tIEEE80211_TX_CTRL_DONT_REORDER;\n2175:\t\t\t\tbreak;\n2176:\t\n2177:\t\t\tcase IEEE80211_RADIOTAP_RATE:\n2178:\t\t\t\trate = *iterator.this_arg;\n2179:\t\t\t\trate_flags = 0;\n2180:\t\t\t\trate_found = true;\n2181:\t\t\t\tbreak;\n2182:\t\n2183:\t\t\tcase IEEE80211_RADIOTAP_ANTENNA:\n2184:\t\t\t\t/* this can appear multiple times, keep a bitmap */\n2185:\t\t\t\t/* control.antennas is only a 2-bit bitmap */\n2186:\t\t\t\tif (*iterator.this_arg \u003c 2)\n2187:\t\t\t\t\tinfo-\u003econtrol.antennas |= BIT(*iterator.this_arg);\n2188:\t\t\t\tbreak;\n2189:\t\n2190:\t\t\tcase IEEE80211_RADIOTAP_DATA_RETRIES:\n2191:\t\t\t\trate_retries = *iterator.this_arg;\n2192:\t\t\t\tbreak;\n2193:\t\n2194:\t\t\tcase IEEE80211_RADIOTAP_MCS:\n2195:\t\t\t\tmcs_known = iterator.this_arg[0];\n"
}

gemini-3.1-pro-preview

null

null

							input: 8509
							output: 41
							thoughts: 423
						

**Fuzzing Plan for Radiotap Header Parsing**

Okay, so I've been looking at this `ieee80211_parse_tx_radiotap` function, and it's definitely reachable and testable. The whole point is it parses radiotap headers from injected packets – which is exactly what we need to fuzz given the patch introduces a `trim_fcs` argument, changing the behavior of the FCS handling. If `trim_fcs` is true, it trims the FCS trailer and if it is false, it doesn't trim it, but validates the length.

The good news is that we can definitely inject these packets. We can use the fuzzer to inject packets with radiotap headers through `mac80211_hwsim` or, if it’s a monitor interface, through tun/tap. Wait, yeah, monitor interfaces! Mac80211 monitor interfaces *can* be created, and we *can* inject packets into them. That's excellent! The `MAC80211_HWSIM` config looks solid, and obviously, `MAC80211` is essential.

Now, let's make sure we've identified the right execution paths. I need to make sure this `ieee80211_parse_tx_radiotap` is called. Let me see... I should check `ieee80211_monitor_select_queue` and `ieee80211_monitor_start_xmit`. Right! `ieee80211_monitor_start_xmit` is the `ndo_start_xmit` for monitor interfaces! So, injecting packets into a monitor interface will trigger this function. The fuzzer can do this by creating a monitor interface and sending packets to it. Perfect, this is definitely worth fuzzing. We are going to hammer this with fuzzers!

Okay, let's identify the specific functions. Definitely `ieee80211_parse_tx_radiotap` is the main target. Also, `ieee80211_monitor_start_xmit` is another key one, and `ieee80211_monitor_select_queue` is also reachable.

Finally, just a quick check for dependencies. We know `MAC80211` and `MAC80211_HWSIM` are the primary configs needed, but I'll double-check to make sure there aren't any other hidden dependencies. I'll check `MAC80211_HWSIM`'s dependencies just to be completely sure.

{
  "Expression": "config MAC80211_HWSIM",
  "PathPrefix": "drivers/net/wireless/virtual/Kconfig"
}

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

gemini-3.1-pro-preview

null

null

							input: 9617
							output: 36
							thoughts: 20
						

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

**Diving into the `MAC80211_HWSIM` Definition**

Okay, so I'm looking at `MAC80211_HWSIM`. I know it's related to the mac80211 framework, obviously. But I need to go deeper than just the name. My initial thought is to pull up the full definition – I want to understand exactly what this thing *is* at a code level. What does this macro stand for? What implications does that have on the framework's behavior? Is it a compile-time flag, a struct definition, or something else entirely? The specifics of the definition will reveal crucial insights, especially in relation to hardware simulation. Does it tie into the internal structures, and if so, how? I need to understand its relationship to the various layers of the mac80211 stack. Ultimately, my goal here is to grasp the practical consequences of its presence or absence within the system. Let's see it in the context of the larger framework.

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

{
  "Contents": "   1:\tconfig MAC80211_HWSIM\n   2:\t\ttristate \"Simulated radio testing tool for mac80211\"\n   3:\t\tdepends on MAC80211\n   4:\t\thelp\n   5:\t\t  This driver is a developer testing tool that can be used to test\n   6:\t\t  IEEE 802.11 networking stack (mac80211) functionality. This is not\n   7:\t\t  needed for normal wireless LAN usage and is only for testing. See\n   8:\t\t  Documentation/networking/mac80211_hwsim for more information on how\n   9:\t\t  to use this tool.\n  10:\t\n  11:\t\t  To compile this driver as a module, choose M here: the module will be\n  12:\t\t  called mac80211_hwsim.  If unsure, say N.\n  13:\t\n  14:\tconfig VIRT_WIFI\n  15:\t\ttristate \"Wifi wrapper for ethernet drivers\"\n  16:\t\tdepends on CFG80211\n  17:\t\thelp\n  18:\t\t  This option adds support for ethernet connections to appear as if they\n  19:\t\t  are wifi connections through a special rtnetlink device.\n  20:\t\n"
}

gemini-3.1-pro-preview

null

null

							input: 10233
							output: 34
							thoughts: 57
						

Okay, here's my take on those dependencies, from an expert's perspective:

**Deep Dive into Wireless Driver Dependencies**

Alright, let's break this down. My initial thought process is straightforward when I see these dependencies. `MAC80211_HWSIM` – right, that's the hardware simulation module for MAC80211, it's pretty clear that it has a direct dependence on the main `MAC80211` framework. No surprises there. It would be bizarre if it *didn't* depend on it. That's a fundamental architectural given.

Now, `MAC80211` itself... ah yes, that's built on `CFG80211`. That's the core. `CFG80211` provides the configuration and regulatory domain interface for 802.11 devices in the Linux kernel. It's the abstraction layer. Everything else, `MAC80211`, the hardware simulations, all use `CFG80211`.

So, the logical next step for me, and I'm sure I'm not alone, is to quickly drill down and make sure `CFG80211` is sound. What's the status of that interface? Is it working as expected? No point spending time on the downstream bits if the foundation isn't solid. I'd want to check its version, any recent patches, known bugs, any regressions it might have introduced. Basically, a quick diagnostic on the lowest level is the logical starting point.

{
  "Expression": "config CFG80211",
  "PathPrefix": "net/wireless/Kconfig"
}

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

gemini-3.1-pro-preview

null

null

							input: 11581
							output: 46
							thoughts: 164
						

**My Initial Thoughts on WiFi Configuration**

Okay, so I'm looking at this `CFG80211` stuff, which is obviously the configuration interface for cfg80211, makes sense. Now, let's see, to get the core functionality I need, I'll definitely want to enable `MAC80211`, `MAC80211_HWSIM`, and of course `CFG80211`. Right, *that* driver, `MAC80211_HWSIM`, is useful, I should remember to include that.

I've got a mental checklist of key functions I'm focusing on – `ieee80211_parse_tx_radiotap`, `ieee80211_monitor_start_xmit`, and `ieee80211_monitor_select_queue`. I need to ensure these are configured correctly.

Let me just quickly verify if `ieee80211_monitor_select_queue` is static. Gotta be sure.

{
  "Expression": "ieee80211_monitor_select_queue",
  "PathPrefix": "net/mac80211/iface.c"
}

{
  "Output": "net/mac80211/iface.c=941=static const struct net_device_ops ieee80211_dataif_ops = {\n--\nnet/mac80211/iface.c-950-\nnet/mac80211/iface.c:951:static u16 ieee80211_monitor_select_queue(struct net_device *dev,\nnet/mac80211/iface.c-952-\t\t\t\t\t  struct sk_buff *skb,\n--\nnet/mac80211/iface.c=979=static const struct net_device_ops ieee80211_monitorif_ops = {\n--\nnet/mac80211/iface.c-985-\t.ndo_set_mac_address \t= ieee80211_change_mac,\nnet/mac80211/iface.c:986:\t.ndo_select_queue\t= ieee80211_monitor_select_queue,\nnet/mac80211/iface.c-987-};\n"
}

gemini-3.1-pro-preview

null

null

							input: 12322
							output: 47
							thoughts: 34
						

Okay, here's my interpretation of those thoughts, framed as an expert's internal monologue:

**Assessing the Codebase: Static vs. Non-Static Functions**

Right, let's take a look at this `ieee80211_parse_tx_radiotap` function. The code seems pretty stable; it's static in nature, which makes it good in a lot of ways. However, while static functions offer benefits, my general preference is to avoid them whenever a non-static option serves the same purpose as the code becomes less flexible and re-usable. Now, I see this particular function isn't marked as static, which is a good thing and makes this code more re-usable. Good. It's important to keep that in mind when doing a code review.

{
  "Expression": "ieee80211_parse_tx_radiotap",
  "PathPrefix": "net/mac80211/tx.c"
}

{
  "Output": "net/mac80211/tx.c=2079=static bool ieee80211_validate_radiotap_len(struct sk_buff *skb)\n--\nnet/mac80211/tx.c-2098-\nnet/mac80211/tx.c:2099:bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\nnet/mac80211/tx.c-2100-\t\t\t\t struct net_device *dev, bool trim_fcs)\n--\nnet/mac80211/tx.c=2318=netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,\n--\nnet/mac80211/tx.c-2473-\t */\nnet/mac80211/tx.c:2474:\tif (!ieee80211_parse_tx_radiotap(skb, dev, true))\nnet/mac80211/tx.c-2475-\t\tgoto fail_rcu;\n"
}

gemini-3.1-pro-preview

null

null

							input: 12873
							output: 46
							thoughts: 42
						

Okay, here's my take on those code elements, thinking through them as I would if I were analyzing them.

**Analyzing IEEE 802.11 TX Path**

Alright, so I'm taking a look at this wireless driver, focusing on the transmit path. I see two key functions flagged here. The first, `ieee80211_parse_tx_radiotap`, and the second, `ieee80211_monitor_start_xmit`. The fact that neither of these is declared `static` immediately grabs my attention. That implies they have external linkage. Now, considering the context of a wireless driver, that could mean a few things, and I need to explore the implications.

If they weren't static, it points to these functions being potentially callable from modules or other parts of the kernel outside the immediate driver code itself. `ieee80211_parse_tx_radiotap` is responsible for parsing a radiotap header on transmit, which seems relatively self-contained, but the fact that it is not static tells me that there is probably an external module that is consuming this parsed information. This also implies it is probably not specific to a single device or even a single driver instance. I need to figure out where that external call is coming from. Could it be a generic monitoring subsystem, maybe some sort of packet capture tool, or even a higher-level wireless management component? This non-static declaration is a critical clue about how this function integrates with the system.

`ieee80211_monitor_start_xmit` also being non-static presents another set of intriguing possibilities. `start_xmit` implies that it is the initial call to the driver's transmit functions. It is probably the call that is used from the network stack to place a packet on the air. So the fact that this is *not* `static` is also important. This would tell me that the driver's interface is exposed, and potentially callable from a monitoring module or generic transmit API. So, if I'm designing a system where I want to hook in and maybe manipulate packets before they go out, or if I am building some sort of virtual interface, this function's visibility becomes highly useful.

In short, the non-static nature of these functions strongly suggests modularity and inter-component communication within this wireless stack. It means I need to trace the calling contexts carefully to understand how these pieces fit together and who's leveraging these interfaces. This is the first place I'd start looking at how to extend or customize the transmission process.

{
  "Expression": "ieee80211_monitor_start_xmit",
  "PathPrefix": "net/mac80211/tx.c"
}

{
  "Output": "net/mac80211/tx.c=2099=bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,\n--\nnet/mac80211/tx.c-2317-\nnet/mac80211/tx.c:2318:netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,\nnet/mac80211/tx.c-2319-\t\t\t\t\t struct net_device *dev)\n"
}

gemini-3.1-pro-preview

null

null

							input: 13662
							output: 178
							thoughts: 181
						

**My Analysis of the Patch**

Okay, so I've pinpointed `ieee80211_parse_tx_radiotap` and `ieee80211_monitor_start_xmit` as key FocusSymbols here. Good start. Let's see... the logic of the patch is about trimming the FCS trailer from injected packets. That definitely touches the core mac80211 stack, so I need to understand the reachability of this change. Since it is optional, I have to consider the options.

My initial assumption is confirmed: this function is reached when injecting packets into a mac80211 monitor interface. And the mac80211_hwsim driver is a perfect tool to test this functionality. I need to make sure I understand the interaction between `MAC80211`, `MAC80211_HWSIM`, and `CFG80211` to fully grasp the configuration dependencies and implications. It’s definitely a functional change that requires detailed testing within that core networking stack.

Alright, I think I've got a handle on the essential components and dependencies. Time to formally set the results.

{
  "EnableConfigs": [
    "MAC80211",
    "MAC80211_HWSIM",
    "CFG80211"
  ],
  "FocusSymbols": [
    "ieee80211_parse_tx_radiotap",
    "ieee80211_monitor_start_xmit"
  ],
  "Reasoning": "The patch modifies `ieee80211_parse_tx_radiotap` to optionally trim the FCS trailer from injected packets. This function is reachable when injecting packets into a mac80211 monitor interface, which can be tested using the mac80211_hwsim driver. This is a functional change in the core mac80211 networking stack.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MAC80211",
    "MAC80211_HWSIM",
    "CFG80211"
  ],
  "FocusSymbols": [
    "ieee80211_parse_tx_radiotap",
    "ieee80211_monitor_start_xmit"
  ],
  "Reasoning": "The patch modifies `ieee80211_parse_tx_radiotap` to optionally trim the FCS trailer from injected packets. This function is reachable when injecting packets into a mac80211 monitor interface, which can be tested using the mac80211_hwsim driver. This is a functional change in the core mac80211 networking stack.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "The patch fixes a logic bug where `skb_trim` was incorrectly called during `ieee80211_monitor_select_queue` when parsing the radiotap header. Trimming the FCS trailer at this stage reduced `skb-\u003elen`, causing the subsequent call to `ieee80211_parse_tx_radiotap` in `ieee80211_monitor_start_xmit` to fail its length check (`skb-\u003elen \u003c (iterator._max_length + FCS_LEN)`) and drop the packet. The fix introduces a `trim_fcs` boolean to defer the trimming until `ieee80211_monitor_start_xmit`.\n\nThis is a logic bug related to packet length manipulation and does not involve uninitialized memory allocations, accesses, or info-leaks. Standard KASAN and other bug detectors are sufficient for catching memory corruption or out-of-bounds issues in this area. 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.

For your convenience, here is the diff of the changes:
commit f088809e9cee102d9b350759d31ddad04d40a83b
Author: syz-cluster <triage@syzkaller.com>
Date:   Tue Aug 18 00:28:57 2026 +0000

    syz-cluster: applied patch under review

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4f95da023746f..0becd3361010f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -7615,11 +7615,12 @@ bool ieee80211_tx_prepare_skb(struct ieee80211_hw *hw,
  *
  * @skb: packet injected by userspace
  * @dev: the &struct device of this 802.11 device
+ * @trim_fcs: trim the FCS trailer when present; validate it otherwise
  *
  * Return: %true if the radiotap header was parsed, %false otherwise
  */
 bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
-				 struct net_device *dev);
+				 struct net_device *dev, bool trim_fcs);
 
 /**
  * struct ieee80211_noa_data - holds temporary data for tracking P2P NoA state
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 43460a705a6bd..fdac729ca580d 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -964,7 +964,7 @@ static u16 ieee80211_monitor_select_queue(struct net_device *dev,
 	/* reset flags and info before parsing radiotap header */
 	memset(info, 0, sizeof(*info));
 
-	if (!ieee80211_parse_tx_radiotap(skb, dev))
+	if (!ieee80211_parse_tx_radiotap(skb, dev, false))
 		return 0; /* doesn't matter, frame will be dropped */
 
 	len_rthdr = ieee80211_get_radiotap_len(skb->data);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91b14112e24f0..97990039695db 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2097,7 +2097,7 @@ static bool ieee80211_validate_radiotap_len(struct sk_buff *skb)
 }
 
 bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
-				 struct net_device *dev)
+				 struct net_device *dev, bool trim_fcs)
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
 	struct ieee80211_radiotap_iterator iterator;
@@ -2154,7 +2154,8 @@ bool ieee80211_parse_tx_radiotap(struct sk_buff *skb,
 				if (skb->len < (iterator._max_length + FCS_LEN))
 					return false;
 
-				skb_trim(skb, skb->len - FCS_LEN);
+				if (trim_fcs)
+					skb_trim(skb, skb->len - FCS_LEN);
 			}
 			if (*iterator.this_arg & IEEE80211_RADIOTAP_F_WEP)
 				info->flags &= ~IEEE80211_TX_INTFL_DONT_ENCRYPT;
@@ -2470,7 +2471,7 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
 	 * selected chandef above to accurately set injection rates and
 	 * retransmissions.
 	 */
-	if (!ieee80211_parse_tx_radiotap(skb, dev))
+	if (!ieee80211_parse_tx_radiotap(skb, dev, true))
 		goto fail_rcu;
 
 	/* remove the injection radiotap header */

gemini-3.1-pro-preview

null

null

							input: 2940
							output: 244
							thoughts: 1235
						

**Analysis of the FCS Trimming Logic in mac80211**

Okay, so I've been looking at this patch for `ieee80211_parse_tx_radiotap` in `net/mac80211`. The core change introduces a `trim_fcs` argument to that function. The intention is to control whether the FCS trailer is removed from the radiotap header during parsing. Initially, I thought this might be related to a KMSAN (Kernel Memory Sanitizer) issue, potentially related to uninitialized memory, but after reviewing the code, it's a completely different problem.

Specifically, the code's behavior in `ieee80211_monitor_select_queue` and `ieee80211_monitor_start_xmit` caught my attention. The former is called *before* the latter, and they both parse the radiotap header. `ieee80211_monitor_select_queue` now *doesn't* trim the FCS (because `trim_fcs` is `false`), and `ieee80211_monitor_start_xmit` *does* trim the FCS (because `trim_fcs` is `true`). This is the fix. The original logic, I suspect, was that `ieee80211_monitor_select_queue` was *incorrectly* trimming the FCS, and then `ieee80211_monitor_start_xmit` was being called, also attempting to parse the already-trimmed header.

Looking at the code snippet, if `trim_fcs` is true, then `skb_trim(skb, skb->len - FCS_LEN)` will be called. If a previous function has already trimmed the FCS, and we check the length after it has been trimmed, the check `if (skb->len < (iterator._max_length + FCS_LEN))` is going to fail, likely resulting in a packet being dropped. This is the precise scenario we are trying to avoid.

The issue is this check is what determines the problem. The core bug here isn't related to uninitialized memory or KMSAN. It is a logic error: an incorrect sequence of operations involving `skb_trim` and subsequent length checks. The length is being altered in an unexpected way, causing a packet drop because the radiotap header parsing fails. It means frames with FCS are being dropped due to a mismatched expectation of the skb length. Therefore, this is not an uninitialized memory issue. The bug is about packet drops caused by an incorrect length check after FCS trimming.

Therefore, NeedsKMSAN should be set to false.

{
  "KMSANReasoning": "The patch fixes a logic bug where `skb_trim` was incorrectly called during `ieee80211_monitor_select_queue` when parsing the radiotap header. Trimming the FCS trailer at this stage reduced `skb-\u003elen`, causing the subsequent call to `ieee80211_parse_tx_radiotap` in `ieee80211_monitor_start_xmit` to fail its length check (`skb-\u003elen \u003c (iterator._max_length + FCS_LEN)`) and drop the packet. The fix introduces a `trim_fcs` boolean to defer the trimming until `ieee80211_monitor_start_xmit`.\n\nThis is a logic bug related to packet length manipulation and does not involve uninitialized memory allocations, accesses, or info-leaks. Standard KASAN and other bug detectors are sufficient for catching memory corruption or out-of-bounds issues in this area. A dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "The patch fixes a logic bug where `skb_trim` was incorrectly called during `ieee80211_monitor_select_queue` when parsing the radiotap header. Trimming the FCS trailer at this stage reduced `skb-\u003elen`, causing the subsequent call to `ieee80211_parse_tx_radiotap` in `ieee80211_monitor_start_xmit` to fail its length check (`skb-\u003elen \u003c (iterator._max_length + FCS_LEN)`) and drop the packet. The fix introduces a `trim_fcs` boolean to defer the trimming until `ieee80211_monitor_start_xmit`.\n\nThis is a logic bug related to packet length manipulation and does not involve uninitialized memory allocations, accesses, or info-leaks. Standard KASAN and other bug detectors are sufficient for catching memory corruption or out-of-bounds issues in this area. A dedicated KMSAN fuzzing session is not required.",
  "NeedsKMSAN": false
}