AI Trajectory

null

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "MWIFIEX_SDIO"
  ],
  "FocusSymbols": [
    "mwifiex_usb_recv",
    "mwifiex_decode_rx_packet"
  ],
  "Reasoning": "The patch fixes out-of-bounds read/write issues in the Marvell WiFi-Ex driver when handling MWIFIEX_TYPE_EVENT packets. The USB part of the driver is reachable via USB fuzzing (e.g. dummy_hcd).",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit f3f616cb3199c3f997025e863209e229df0f8878\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Fri Jul 24 06:37:41 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c\nindex f039d6f19183a5..3588c36f64cfda 100644\n--- a/drivers/net/wireless/marvell/mwifiex/sdio.c\n+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c\n@@ -1712,12 +1712,19 @@ static int mwifiex_decode_rx_packet(struct mwifiex_adapter *adapter,\n \tcase MWIFIEX_TYPE_EVENT:\n \t\tmwifiex_dbg(adapter, EVENT,\n \t\t\t    \"info: --- Rx: Event ---\\n\");\n+\t\tif (skb-\u003elen \u003c MWIFIEX_EVENT_HEADER_LEN ||\n+\t\t    skb-\u003elen \u003e MAX_EVENT_SIZE) {\n+\t\t\tmwifiex_dbg(adapter, ERROR,\n+\t\t\t\t    \"EVENT: invalid skb-\u003elen %u\\n\", skb-\u003elen);\n+\t\t\tdev_kfree_skb_any(skb);\n+\t\t\tbreak;\n+\t\t}\n+\n \t\tadapter-\u003eevent_cause = get_unaligned_le32(skb-\u003edata);\n \n-\t\tif ((skb-\u003elen \u003e 0) \u0026\u0026 (skb-\u003elen  \u003c MAX_EVENT_SIZE))\n-\t\t\tmemcpy(adapter-\u003eevent_body,\n-\t\t\t       skb-\u003edata + MWIFIEX_EVENT_HEADER_LEN,\n-\t\t\t       skb-\u003elen);\n+\t\tmemcpy(adapter-\u003eevent_body,\n+\t\t       skb-\u003edata + MWIFIEX_EVENT_HEADER_LEN,\n+\t\t       skb-\u003elen - MWIFIEX_EVENT_HEADER_LEN);\n \n \t\t/* event cause has been saved to adapter-\u003eevent_cause */\n \t\tadapter-\u003eevent_received = true;\ndiff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c\nindex f4b94a1054f650..a6ed82e7228b11 100644\n--- a/drivers/net/wireless/marvell/mwifiex/usb.c\n+++ b/drivers/net/wireless/marvell/mwifiex/usb.c\n@@ -110,7 +110,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter *adapter,\n \t\t\t}\n \n \t\t\tmemcpy(adapter-\u003eevent_body, skb-\u003edata +\n-\t\t\t       MWIFIEX_EVENT_HEADER_LEN, skb-\u003elen);\n+\t\t\t       MWIFIEX_EVENT_HEADER_LEN,\n+\t\t\t       skb-\u003elen - MWIFIEX_EVENT_HEADER_LEN);\n \n \t\t\tadapter-\u003eevent_received = true;\n \t\t\tadapter-\u003eevent_skb = skb;\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "MWIFIEX_SDIO"
  ],
  "FocusSymbols": [
    "mwifiex_usb_recv",
    "mwifiex_decode_rx_packet"
  ],
  "Reasoning": "The patch fixes out-of-bounds read/write issues in the Marvell WiFi-Ex driver when handling MWIFIEX_TYPE_EVENT packets. The USB part of the driver is reachable via USB fuzzing (e.g. dummy_hcd).",
  "WorthFuzzing": true
}

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

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

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).

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

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Do not list too generic configs (we already have them enabled). Only list those that
   specifically cover the modified code. List them in the EnableConfigs output array,
   and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


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

For your convenience, here is the diff of the changes:
commit f3f616cb3199c3f997025e863209e229df0f8878
Author: syz-cluster <triage@syzkaller.com>
Date:   Fri Jul 24 06:37:41 2026 +0000

    syz-cluster: applied patch under review

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index f039d6f19183a5..3588c36f64cfda 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1712,12 +1712,19 @@ static int mwifiex_decode_rx_packet(struct mwifiex_adapter *adapter,
 	case MWIFIEX_TYPE_EVENT:
 		mwifiex_dbg(adapter, EVENT,
 			    "info: --- Rx: Event ---\n");
+		if (skb->len < MWIFIEX_EVENT_HEADER_LEN ||
+		    skb->len > MAX_EVENT_SIZE) {
+			mwifiex_dbg(adapter, ERROR,
+				    "EVENT: invalid skb->len %u\n", skb->len);
+			dev_kfree_skb_any(skb);
+			break;
+		}
+
 		adapter->event_cause = get_unaligned_le32(skb->data);
 
-		if ((skb->len > 0) && (skb->len  < MAX_EVENT_SIZE))
-			memcpy(adapter->event_body,
-			       skb->data + MWIFIEX_EVENT_HEADER_LEN,
-			       skb->len);
+		memcpy(adapter->event_body,
+		       skb->data + MWIFIEX_EVENT_HEADER_LEN,
+		       skb->len - MWIFIEX_EVENT_HEADER_LEN);
 
 		/* event cause has been saved to adapter->event_cause */
 		adapter->event_received = true;
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index f4b94a1054f650..a6ed82e7228b11 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -110,7 +110,8 @@ static int mwifiex_usb_recv(struct mwifiex_adapter *adapter,
 			}
 
 			memcpy(adapter->event_body, skb->data +
-			       MWIFIEX_EVENT_HEADER_LEN, skb->len);
+			       MWIFIEX_EVENT_HEADER_LEN,
+			       skb->len - MWIFIEX_EVENT_HEADER_LEN);
 
 			adapter->event_received = true;
 			adapter->event_skb = skb;

gemini-3.1-pro-preview

null

null

							input: 2406
							output: 38
							thoughts: 217
						

**Analyzing a WiFi Driver Patch**

Alright, let's break this down. I've got a patch here that's touching two crucial files within the Marvell WiFi driver: `sdio.c` and `usb.c`. My initial read tells me this is likely aimed at shoring up some security vulnerabilities, specifically related to how the driver handles `MWIFIEX_TYPE_EVENT` packets. Sounds like we're fixing a potential out-of-bounds read or write, or maybe even a buffer overflow, depending on how things were being handled before.

In `mwifiex_decode_rx_packet` within `sdio.c`, the patch seems to add a crucial sanity check: it's verifying that the incoming packet's length, `skb->len`, falls within a reasonable window, specifically comparing it against `MWIFIEX_EVENT_HEADER_LEN` and `MAX_EVENT_SIZE`. Smart. That's the first line of defense. They also tweaked the `memcpy` length. It looks like they're now subtracting `MWIFIEX_EVENT_HEADER_LEN` from `skb->len` to ensure we don't copy more data than we're supposed to.

The same pattern is replicated in `mwifiex_usb_recv`, but this time in `usb.c`. Here, they've also changed the `memcpy` length using the same logic. This probably means they were missing these checks previously. This consistency suggests a systemic issue that's been addressed across both the SDIO and USB implementations of the driver.

Before I go any further, I should verify the `Kconfig` for `mwifiex`. I want to make sure it's enabled and any relevant configurations are set before diving deeper into the code. This will help me understand the full scope of this change and its impact on different device configurations.

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

{
  "Output": "drivers/net/wireless/marvell/mwifiex/Kconfig-1-# SPDX-License-Identifier: GPL-2.0-only\ndrivers/net/wireless/marvell/mwifiex/Kconfig:2:config MWIFIEX\ndrivers/net/wireless/marvell/mwifiex/Kconfig-3-\ttristate \"Marvell WiFi-Ex Driver\"\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-11-\ndrivers/net/wireless/marvell/mwifiex/Kconfig:12:config MWIFIEX_SDIO\ndrivers/net/wireless/marvell/mwifiex/Kconfig-13-\ttristate \"Marvell WiFi-Ex Driver for SD8786/SD8787/SD8797/SD8887/SD8897/SD8977/SD8978/SD8987/SD8997\"\ndrivers/net/wireless/marvell/mwifiex/Kconfig:14:\tdepends on MWIFIEX \u0026\u0026 MMC\ndrivers/net/wireless/marvell/mwifiex/Kconfig-15-\tselect FW_LOADER\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-24-\ndrivers/net/wireless/marvell/mwifiex/Kconfig:25:config MWIFIEX_PCIE\ndrivers/net/wireless/marvell/mwifiex/Kconfig-26-\ttristate \"Marvell WiFi-Ex Driver for PCIE 8766/8897/8997\"\ndrivers/net/wireless/marvell/mwifiex/Kconfig:27:\tdepends on MWIFIEX \u0026\u0026 PCI\ndrivers/net/wireless/marvell/mwifiex/Kconfig-28-\tselect FW_LOADER\n--\ndrivers/net/wireless/marvell/mwifiex/Kconfig-36-\ndrivers/net/wireless/marvell/mwifiex/Kconfig:37:config MWIFIEX_USB\ndrivers/net/wireless/marvell/mwifiex/Kconfig-38-\ttristate \"Marvell WiFi-Ex Driver for USB8766/8797/8997\"\ndrivers/net/wireless/marvell/mwifiex/Kconfig:39:\tdepends on MWIFIEX \u0026\u0026 USB\ndrivers/net/wireless/marvell/mwifiex/Kconfig-40-\tselect FW_LOADER\n"
}

gemini-3.1-pro-preview

null

null

							input: 3646
							output: 46
							thoughts: 107
						

**Analyzing the MWIFIEX Driver Code**

Okay, so I'm looking at the configurations, focusing on MWIFIEX, MWIFIEX_SDIO, and MWIFIEX_USB. I need to understand the data flow, and it looks like `mwifiex_decode_rx_packet` and `mwifiex_usb_recv` are key functions here. Let me quickly confirm their locations; I believe `mwifiex_decode_rx_packet` is implemented within `sdio.c` and `mwifiex_usb_recv` in `usb.c`. Yes, that's correct, a quick check confirms they're in the expected files. Now that I have the key functions for different interfaces, I need to see if there are any other areas I need to investigate, or if there is additional data flow I should focus on.

{
  "Expression": "mwifiex_decode_rx_packet",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/sdio.c"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/sdio.c=1593=static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1646- */\ndrivers/net/wireless/marvell/mwifiex/sdio.c:1647:static int mwifiex_decode_rx_packet(struct mwifiex_adapter *adapter,\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1648-\t\t\t\t    struct sk_buff *skb, u32 upld_typ)\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c=1754=static int mwifiex_sdio_card_to_host_mp_aggr(struct mwifiex_adapter *adapter,\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1904-\t\t\t\t/* Process de-aggr packet */\ndrivers/net/wireless/marvell/mwifiex/sdio.c:1905:\t\t\t\tmwifiex_decode_rx_packet(adapter, skb_deaggr,\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1906-\t\t\t\t\t\t\t pkt_type);\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1952-\ndrivers/net/wireless/marvell/mwifiex/sdio.c:1953:\t\tmwifiex_decode_rx_packet(adapter, skb, pkt_type);\ndrivers/net/wireless/marvell/mwifiex/sdio.c-1954-\t}\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c=1989=static int mwifiex_process_int_status(struct mwifiex_adapter *adapter)\n--\ndrivers/net/wireless/marvell/mwifiex/sdio.c-2051-\ndrivers/net/wireless/marvell/mwifiex/sdio.c:2052:\t\tmwifiex_decode_rx_packet(adapter, skb, pkt_type);\ndrivers/net/wireless/marvell/mwifiex/sdio.c-2053-\t}\n"
}

gemini-3.1-pro-preview

null

null

							input: 4557
							output: 43
							thoughts: 163
						

**Reaching the Target Functions**

Okay, so I'm looking at `mwifiex_decode_rx_packet` and `mwifiex_usb_recv`. The question is, can I trigger these within a virtualized environment? USB, that's definitely a good target for fuzzing. I can use `dummy_hcd` or leverage syzkaller's USB fuzzer. That seems straightforward.

What about SDIO? I'm less certain about SDIO fuzzing. I don't recall a truly *generic* SDIO fuzzer off the top of my head. Maybe syzkaller has some SDIO support, I'll have to investigate further. Wait, no, syzkaller isn't a generic SDIO fuzzer. However, it *might* be reachable with emulation, which changes things. Ah, but that's a distraction. Right, syzkaller *does* have a USB fuzzer.

Okay, that's it! Since `mwifiex_usb_recv` deals with USB, that's definitely reachable via USB fuzzing. That's good news. So, let's turn my attention to that function specifically. Let's see what's in `mwifiex_usb_recv`.

{
  "Expression": "mwifiex_usb_recv",
  "PathPrefix": "drivers/net/wireless/marvell/mwifiex/usb.c"
}

{
  "Output": "drivers/net/wireless/marvell/mwifiex/usb.c=41=static int mwifiex_usb_submit_rx_urb(struct urb_context *ctx, int size);\n--\ndrivers/net/wireless/marvell/mwifiex/usb.c-45- */\ndrivers/net/wireless/marvell/mwifiex/usb.c:46:static int mwifiex_usb_recv(struct mwifiex_adapter *adapter,\ndrivers/net/wireless/marvell/mwifiex/usb.c-47-\t\t\t    struct sk_buff *skb, u8 ep)\n--\ndrivers/net/wireless/marvell/mwifiex/usb.c=153=static void mwifiex_usb_rx_complete(struct urb *urb)\n--\ndrivers/net/wireless/marvell/mwifiex/usb.c-187-\ndrivers/net/wireless/marvell/mwifiex/usb.c:188:\t\tstatus = mwifiex_usb_recv(adapter, skb, context-\u003eep);\ndrivers/net/wireless/marvell/mwifiex/usb.c-189-\n--\ndrivers/net/wireless/marvell/mwifiex/usb.c-197-\t\t\t * urb for cmd_ep will be re-submitted in callback\ndrivers/net/wireless/marvell/mwifiex/usb.c:198:\t\t\t * mwifiex_usb_recv_complete\ndrivers/net/wireless/marvell/mwifiex/usb.c-199-\t\t\t */\n"
}

gemini-3.1-pro-preview

null

null

							input: 5415
							output: 127
							thoughts: 297
						

**Fuzzing Target Identification**

Okay, so the `mwifiex_usb_recv` function is definitely a good candidate for fuzzing, given that it's called directly from `mwifiex_usb_rx_complete`, which is a USB URB completion handler. This path is known to be reachable via the USB fuzzer, so that's a straightforward win.

Now, let's consider `mwifiex_decode_rx_packet`. It's defined in `sdio.c`, which makes me immediately think about potential SDIO fuzzing opportunities. While I haven't specifically confirmed SDIO fuzzing is already in place, the USB path to `mwifiex_decode_rx_packet` still exists, and we can target this function through it.

Therefore, for this particular analysis, I'm confident we can set `WorthFuzzing=true`. My focus will be on these two functions: `mwifiex_usb_recv` and `mwifiex_decode_rx_packet`. I know that `MWIFIEX`, `MWIFIEX_USB`, and `MWIFIEX_SDIO` configurations are relevant to enabling this fuzzing.

Just to be absolutely sure, let's quickly re-examine the call graph. It looks like `mwifiex_usb_rx_complete` is the direct caller of `mwifiex_usb_recv`, as expected. Also, `mwifiex_process_int_status`, `mwifiex_sdio_card_to_host_mp_aggr`, and `mwifiex_deaggr_sdio_pkt` all call `mwifiex_decode_rx_packet`. But for now, I'm sticking with `mwifiex_usb_recv` and `mwifiex_decode_rx_packet` as our primary targets.

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "MWIFIEX_SDIO"
  ],
  "FocusSymbols": [
    "mwifiex_usb_recv",
    "mwifiex_decode_rx_packet"
  ],
  "Reasoning": "The patch fixes out-of-bounds read/write issues in the Marvell WiFi-Ex driver when handling MWIFIEX_TYPE_EVENT packets. The USB part of the driver is reachable via USB fuzzing (e.g. dummy_hcd).",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "MWIFIEX",
    "MWIFIEX_USB",
    "MWIFIEX_SDIO"
  ],
  "FocusSymbols": [
    "mwifiex_usb_recv",
    "mwifiex_decode_rx_packet"
  ],
  "Reasoning": "The patch fixes out-of-bounds read/write issues in the Marvell WiFi-Ex driver when handling MWIFIEX_TYPE_EVENT packets. The USB part of the driver is reachable via USB fuzzing (e.g. dummy_hcd).",
  "WorthFuzzing": true
}