| Seq | Timestamp | Type | Name | Duration |
|---|---|---|---|---|
| 0/0 | 2026/07/28 08:46 | flow | patch-triage |
3mArgs:null Results: {
"EnableConfigs": [
"ATH12K",
"MAC80211",
"PCI"
],
"FocusSymbols": [
"ath12k_mac_op_change_vif_links",
"ath12k_mac_op_hw_scan",
"ath12k_mac_op_set_key",
"ath12k_mac_op_sta_state",
"ath12k_mac_op_flush",
"ath12k_mac_op_reconfig_complete",
"ath12k_mac_handle_beacon_miss",
"ath12k_core_restart"
],
"Reasoning": "The patch modifies the ath12k Wi-Fi driver to handle crash recovery and MLO peer ID assignment. Although ath12k is a hardware-specific driver, syzkaller is able to fuzz it using the PCI fuzzer to emulate the device and register it with mac80211, allowing standard nl80211 fuzzing to reach the modified mac80211 ops. The patch contains functional changes to control-path operations that should be fuzzed.",
"WorthFuzzing": true
} |
| 1/1 | 2026/07/28 08:46 | action | read-patch-diff |
0mArgs:null Results: {
"PatchDiff": "commit a8f5928a7ff8d7696cf12bea9b220a14e7f28a85\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate: Tue Jul 28 08:46:14 2026 +0000\n\n syz-cluster: applied patch under review\n\ndiff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c\nindex 742d4fd1b598c2..5c3883b19da155 100644\n--- a/drivers/net/wireless/ath/ath12k/core.c\n+++ b/drivers/net/wireless/ath/ath12k/core.c\n@@ -1410,8 +1410,6 @@ static int ath12k_core_reconfigure_on_crash(struct ath12k_base *ab)\n \tif (ret)\n \t\tgoto err_hal_srng_deinit;\n \n-\tclear_bit(ATH12K_FLAG_RECOVERY, \u0026ab-\u003edev_flags);\n-\n \treturn 0;\n \n err_hal_srng_deinit:\ndiff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c b/drivers/net/wireless/ath/ath12k/dp_peer.c\nindex a12073afc307ce..c086fc297b37f1 100644\n--- a/drivers/net/wireless/ath/ath12k/dp_peer.c\n+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c\n@@ -416,8 +416,10 @@ u16 ath12k_dp_peer_get_peerid_index(struct ath12k_dp *dp, u16 peer_id)\n struct ath12k_dp_peer *ath12k_dp_peer_find_by_peerid(struct ath12k_pdev_dp *dp_pdev,\n \t\t\t\t\t\t u16 peer_id)\n {\n-\tu16 index;\n+\tstruct ath12k_dp_hw *dp_hw = dp_pdev-\u003edp_hw;\n+\tstruct ath12k_dp_peer *dp_peer, *tmp;\n \tstruct ath12k_dp *dp = dp_pdev-\u003edp;\n+\tu16 index;\n \n \tRCU_LOCKDEP_WARN(!rcu_read_lock_held(),\n \t\t\t \"ath12k dp peer find by peerid index called without rcu lock\");\n@@ -426,8 +428,23 @@ struct ath12k_dp_peer *ath12k_dp_peer_find_by_peerid(struct ath12k_pdev_dp *dp_p\n \t\treturn NULL;\n \n \tindex = ath12k_dp_peer_get_peerid_index(dp, peer_id);\n+\tdp_peer = rcu_dereference(dp_hw-\u003edp_peers[index]);\n+\n+\tif (!dp_peer \u0026\u0026 (peer_id \u0026 ATH12K_PEER_ML_ID_VALID)) {\n+\t\tspin_lock_bh(\u0026dp_hw-\u003epeer_lock);\n+\t\tlist_for_each_entry(tmp, \u0026dp_hw-\u003edp_peers_list, list) {\n+\t\t\tif (tmp-\u003eis_mlo \u0026\u0026\n+\t\t\t tmp-\u003epeer_id == ATH12K_DP_PEER_ID_INVALID) {\n+\t\t\t\ttmp-\u003epeer_id = peer_id;\n+\t\t\t\trcu_assign_pointer(dp_hw-\u003edp_peers[index], tmp);\n+\t\t\t\tdp_peer = tmp;\n+\t\t\t\tbreak;\n+\t\t\t}\n+\t\t}\n+\t\tspin_unlock_bh(\u0026dp_hw-\u003epeer_lock);\n+\t}\n \n-\treturn rcu_dereference(dp_pdev-\u003edp_hw-\u003edp_peers[index]);\n+\treturn dp_peer;\n }\n EXPORT_SYMBOL(ath12k_dp_peer_find_by_peerid);\n \n@@ -475,11 +492,11 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,\n \tdp_peer-\u003eis_mlo = params-\u003eis_mlo;\n \n \t/*\n-\t * For MLO client, the host assigns the ML peer ID, so set peer_id in dp_peer\n-\t * For non-MLO client, host gets link peer ID from firmware and will be\n-\t * assigned at the time of link peer creation\n+\t * peer_id starts as INVALID for both MLO and non-MLO clients.\n+\t * For MLO: synced from firmware's first data path descriptor.\n+\t * For non-MLO: assigned at the time of link peer creation.\n \t */\n-\tdp_peer-\u003epeer_id = params-\u003eis_mlo ? params-\u003epeer_id : ATH12K_DP_PEER_ID_INVALID;\n+\tdp_peer-\u003epeer_id = ATH12K_DP_PEER_ID_INVALID;\n \tdp_peer-\u003eucast_ra_only = params-\u003eucast_ra_only;\n \n \tdp_peer-\u003esec_type = HAL_ENCRYPT_TYPE_OPEN;\n@@ -491,15 +508,12 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,\n \tlist_add(\u0026dp_peer-\u003elist, \u0026dp_hw-\u003edp_peers_list);\n \n \t/*\n-\t * For MLO client, the peer_id for ath12k_dp_peer is allocated by host\n-\t * and that peer_id is known at this point, and hence this ath12k_dp_peer\n-\t * can be added to the RCU table using the peer_id.\n+\t * For MLO client, the dp_peers[] RCU table entry will be populated\n+\t * when the firmware's actual peer_id is learned from the first data\n+\t * path descriptor (in ath12k_dp_peer_find_by_peerid).\n \t * For non-MLO client, this addition to RCU table shall be done at the\n \t * time of assignment of ath12k_dp_link_peer to ath12k_dp_peer.\n \t */\n-\tif (dp_peer-\u003eis_mlo)\n-\t\trcu_assign_pointer(dp_hw-\u003edp_peers[dp_peer-\u003epeer_id], dp_peer);\n-\n \tspin_unlock_bh(\u0026dp_hw-\u003epeer_lock);\n \n \treturn 0;\n@@ -518,8 +532,11 @@ void ath12k_dp_peer_delete(struct ath12k_dp_hw *dp_hw, u8 *addr,\n \t\treturn;\n \t}\n \n-\tif (dp_peer-\u003eis_mlo)\n-\t\trcu_assign_pointer(dp_hw-\u003edp_peers[dp_peer-\u003epeer_id], NULL);\n+\tif (dp_peer-\u003eis_mlo) {\n+\t\tif (dp_peer-\u003epeer_id != ATH12K_DP_PEER_ID_INVALID)\n+\t\t\trcu_assign_pointer(dp_hw-\u003edp_peers[dp_peer-\u003epeer_id],\n+\t\t\t\t\t NULL);\n+\t}\n \n \tlist_del(\u0026dp_peer-\u003elist);\n \ndiff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c\nindex 8fa0e90b453160..473855ded8a765 100644\n--- a/drivers/net/wireless/ath/ath12k/dp_rx.c\n+++ b/drivers/net/wireless/ath/ath12k/dp_rx.c\n@@ -751,6 +751,9 @@ int ath12k_dp_rx_ampdu_stop(struct ath12k *ar,\n \n \tlockdep_assert_wiphy(ath12k_ar_to_hw(ar)-\u003ewiphy);\n \n+\tif (test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ab-\u003edev_flags))\n+\t\treturn 0;\n+\n \tarsta = wiphy_dereference(ath12k_ar_to_hw(ar)-\u003ewiphy,\n \t\t\t\t ahsta-\u003elink[link_id]);\n \tif (!arsta)\ndiff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/ath/ath12k/hal.c\nindex a164563fff289c..b78bb9a7cb1fdb 100644\n--- a/drivers/net/wireless/ath/ath12k/hal.c\n+++ b/drivers/net/wireless/ath/ath12k/hal.c\n@@ -376,6 +376,9 @@ int ath12k_hal_srng_src_num_free(struct ath12k_base *ab, struct hal_srng *srng,\n \n \tlockdep_assert_held(\u0026srng-\u003elock);\n \n+\tif (unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ab-\u003edev_flags)))\n+\t\treturn 0;\n+\n \thp = srng-\u003eu.src_ring.hp;\n \n \tif (sync_hw_ptr) {\n@@ -418,6 +421,9 @@ void *ath12k_hal_srng_src_get_next_entry(struct ath12k_base *ab,\n \n \tlockdep_assert_held(\u0026srng-\u003elock);\n \n+\tif (unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ab-\u003edev_flags)))\n+\t\treturn NULL;\n+\n \t/* TODO: Using % is expensive, but we have to do this since size of some\n \t * SRNG rings is not power of 2 (due to descriptor sizes). Need to see\n \t * if separate function is defined for rings having power of 2 ring size\n@@ -523,6 +529,10 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)\n {\n \tlockdep_assert_held(\u0026srng-\u003elock);\n \n+\tif (srng-\u003ering_dir == HAL_SRNG_DIR_SRC \u0026\u0026\n+\t unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ab-\u003edev_flags)))\n+\t\treturn;\n+\n \tif (srng-\u003eflags \u0026 HAL_SRNG_FLAGS_LMAC_RING) {\n \t\t/* For LMAC rings, ring pointer updates are done through FW and\n \t\t * hence written to a shared memory location that is read by FW\ndiff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c\nindex 51c4df32e71695..dfd69822c5ceca 100644\n--- a/drivers/net/wireless/ath/ath12k/mac.c\n+++ b/drivers/net/wireless/ath/ath12k/mac.c\n@@ -1287,13 +1287,16 @@ void ath12k_mac_dp_peer_cleanup(struct ath12k_hw *ah)\n \tspin_lock_bh(\u0026dp_hw-\u003epeer_lock);\n \tlist_for_each_entry_safe(dp_peer, tmp, \u0026dp_hw-\u003edp_peers_list, list) {\n \t\tif (dp_peer-\u003eis_mlo) {\n-\t\t\trcu_assign_pointer(dp_hw-\u003edp_peers[dp_peer-\u003epeer_id], NULL);\n-\t\t\tclear_bit(dp_peer-\u003epeer_id, ah-\u003efree_ml_peer_id_map);\n+\t\t\tif (dp_peer-\u003epeer_id != ATH12K_DP_PEER_ID_INVALID)\n+\t\t\t\trcu_assign_pointer(dp_hw-\u003edp_peers[dp_peer-\u003epeer_id],\n+\t\t\t\t\t\t NULL);\n \t\t}\n \n \t\tlist_move(\u0026dp_peer-\u003elist, \u0026peers);\n \t}\n \n+\tbitmap_zero(ah-\u003efree_ml_peer_id_map, ATH12K_MAX_MLO_PEERS);\n+\n \tspin_unlock_bh(\u0026dp_hw-\u003epeer_lock);\n \n \tsynchronize_rcu();\n@@ -1943,15 +1946,43 @@ static void ath12k_mac_handle_beacon_iter(void *data, u8 *mac,\n \tstruct sk_buff *skb = data;\n \tstruct ieee80211_mgmt *mgmt = (void *)skb-\u003edata;\n \tstruct ath12k_vif *ahvif = ath12k_vif_to_ahvif(vif);\n-\tstruct ath12k_link_vif *arvif = \u0026ahvif-\u003edeflink;\n+\tstruct ieee80211_bss_conf *link_conf;\n+\tstruct ath12k_link_vif *arvif;\n+\tunsigned long links;\n+\tu8 link_id;\n \n-\tif (vif-\u003etype != NL80211_IFTYPE_STATION || !arvif-\u003eis_created)\n+\tif (vif-\u003etype != NL80211_IFTYPE_STATION)\n \t\treturn;\n \n-\tif (!ether_addr_equal(mgmt-\u003ebssid, vif-\u003ebss_conf.bssid))\n+\tif (!ieee80211_vif_is_mld(vif)) {\n+\t\tarvif = \u0026ahvif-\u003edeflink;\n+\t\tif (arvif-\u003eis_created \u0026\u0026\n+\t\t ether_addr_equal(mgmt-\u003ebssid, vif-\u003ebss_conf.bssid))\n+\t\t\tcancel_delayed_work(\u0026arvif-\u003econnection_loss_work);\n \t\treturn;\n+\t}\n \n-\tcancel_delayed_work(\u0026arvif-\u003econnection_loss_work);\n+\t/* For MLO, each link has a different AP BSSID. Check the beacon\n+\t * against all link BSS configs. If any matches, cancel\n+\t * connection_loss_work on all links since it calls per-VIF\n+\t * ieee80211_connection_loss() regardless of which link queued it.\n+\t */\n+\tlinks = ahvif-\u003elinks_map;\n+\tfor_each_set_bit(link_id, \u0026links, IEEE80211_MLD_MAX_NUM_LINKS) {\n+\t\tlink_conf = rcu_dereference(vif-\u003elink_conf[link_id]);\n+\t\tif (link_conf \u0026\u0026\n+\t\t ether_addr_equal(mgmt-\u003ebssid, link_conf-\u003ebssid))\n+\t\t\tgoto found;\n+\t}\n+\n+\treturn;\n+\n+found:\n+\tfor_each_set_bit(link_id, \u0026links, IEEE80211_MLD_MAX_NUM_LINKS) {\n+\t\tarvif = rcu_dereference(ahvif-\u003elink[link_id]);\n+\t\tif (arvif \u0026\u0026 arvif-\u003eis_created)\n+\t\t\tcancel_delayed_work(\u0026arvif-\u003econnection_loss_work);\n+\t}\n }\n \n void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb)\n@@ -1977,9 +2008,16 @@ void ath12k_mac_handle_beacon_miss(struct ath12k *ar,\n \t * (done by mac80211) succeeds but beacons do not resume then it\n \t * doesn't make sense to continue operation. Queue connection loss work\n \t * which can be cancelled when beacon is received.\n+\t *\n+\t * Skip for MLO because connection_loss_work disconnects the entire\n+\t * VIF based on a single link's beacon miss, and its cancellation\n+\t * mechanism (beacon reception via WMI) is unreliable. The mac80211\n+\t * probe triggered by ieee80211_beacon_loss() above is sufficient\n+\t * to detect real AP unreachability.\n \t */\n-\tieee80211_queue_delayed_work(hw, \u0026arvif-\u003econnection_loss_work,\n-\t\t\t\t ATH12K_CONNECTION_LOSS_HZ);\n+\tif (!ieee80211_vif_is_mld(vif))\n+\t\tieee80211_queue_delayed_work(hw, \u0026arvif-\u003econnection_loss_work,\n+\t\t\t\t\t ATH12K_CONNECTION_LOSS_HZ);\n }\n \n static void ath12k_mac_vif_sta_connection_loss_work(struct work_struct *work)\n@@ -4278,6 +4316,9 @@ ath12k_mac_op_change_vif_links(struct ieee80211_hw *hw,\n \n \tlockdep_assert_wiphy(hw-\u003ewiphy);\n \n+\tif (old_links \u0026\u0026 test_bit(ATH12K_FLAG_RECOVERY, \u0026ah-\u003eradio[0].ab-\u003edev_flags))\n+\t\treturn -EINVAL;\n+\n \tath12k_generic_dbg(ATH12K_DBG_MAC,\n \t\t\t \"mac vif link changed for MLD %pM old_links 0x%x new_links 0x%x\\n\",\n \t\t\t vif-\u003eaddr, old_links, new_links);\n@@ -5704,6 +5745,9 @@ int ath12k_mac_op_hw_scan(struct ieee80211_hw *hw,\n \n \tlockdep_assert_wiphy(hw-\u003ewiphy);\n \n+\tif (test_bit(ATH12K_FLAG_RECOVERY, \u0026ah-\u003eradio[0].ab-\u003edev_flags))\n+\t\treturn -EBUSY;\n+\n \tchan_list = kzalloc_objs(*chan_list, hw_req-\u003ereq.n_channels);\n \tif (!chan_list)\n \t\treturn -ENOMEM;\n@@ -5956,6 +6000,9 @@ static int ath12k_clear_peer_keys(struct ath12k_link_vif *arvif,\n \n \tlockdep_assert_wiphy(ath12k_ar_to_hw(ar)-\u003ewiphy);\n \n+\tif (test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ab-\u003edev_flags))\n+\t\treturn 0;\n+\n \tspin_lock_bh(\u0026dp-\u003edp_lock);\n \tpeer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, arvif-\u003evdev_id, addr);\n \tif (!peer || !peer-\u003edp_peer) {\n@@ -6031,6 +6078,8 @@ static int ath12k_mac_set_key(struct ath12k *ar, enum set_key_cmd cmd,\n \t\tspin_unlock_bh(\u0026dp-\u003edp_lock);\n \n \t\tif (cmd == SET_KEY) {\n+\t\t\tif (test_bit(ATH12K_FLAG_RECOVERY, \u0026ab-\u003edev_flags))\n+\t\t\t\treturn 0;\n \t\t\tath12k_warn(ab, \"cannot install key for non-existent peer %pM\\n\",\n \t\t\t\t peer_addr);\n \t\t\treturn -EOPNOTSUPP;\n@@ -7045,7 +7094,8 @@ static int ath12k_mac_station_remove(struct ath12k *ar,\n \n \twiphy_work_cancel(ar-\u003eah-\u003ehw-\u003ewiphy, \u0026arsta-\u003eupdate_wk);\n \n-\tif (ahvif-\u003evdev_type == WMI_VDEV_TYPE_STA) {\n+\tif (ahvif-\u003evdev_type == WMI_VDEV_TYPE_STA \u0026\u0026\n+\t !test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ar-\u003eab-\u003edev_flags)) {\n \t\tath12k_bss_disassoc(ar, arvif);\n \t\tret = ath12k_mac_vdev_stop(arvif);\n \t\tif (ret)\n@@ -7795,7 +7845,8 @@ int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,\n \t * about to move to the associated state.\n \t */\n \tif (ieee80211_vif_is_mld(vif) \u0026\u0026 vif-\u003etype == NL80211_IFTYPE_STATION \u0026\u0026\n-\t old_state == IEEE80211_STA_AUTH \u0026\u0026 new_state == IEEE80211_STA_ASSOC) {\n+\t old_state == IEEE80211_STA_AUTH \u0026\u0026 new_state == IEEE80211_STA_ASSOC \u0026\u0026\n+\t !test_bit(ATH12K_FLAG_RECOVERY, \u0026ah-\u003eradio[0].ab-\u003edev_flags)) {\n \t\t/* TODO: for now only do link selection for single device\n \t\t * MLO case. Other cases would be handled in the future.\n \t\t */\n@@ -12596,6 +12647,9 @@ static int ath12k_mac_flush(struct ath12k *ar)\n \tlong time_left;\n \tint ret = 0;\n \n+\tif (test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ar-\u003eab-\u003edev_flags))\n+\t\treturn -ESHUTDOWN;\n+\n \ttime_left = wait_event_timeout(ar-\u003edp.tx_empty_waitq,\n \t\t\t\t (atomic_read(\u0026ar-\u003edp.num_tx_pending) == 0),\n \t\t\t\t ATH12K_FLUSH_TIMEOUT);\n@@ -13494,6 +13548,8 @@ ath12k_mac_op_reconfig_complete(struct ieee80211_hw *hw,\n \tfor_each_ar(ah, ar, i) {\n \t\tab = ar-\u003eab;\n \n+\t\tclear_bit(ATH12K_FLAG_RECOVERY, \u0026ab-\u003edev_flags);\n+\n \t\tath12k_warn(ar-\u003eab, \"pdev %d successfully recovered\\n\",\n \t\t\t ar-\u003epdev-\u003epdev_id);\n \ndiff --git a/drivers/net/wireless/ath/ath12k/peer.c b/drivers/net/wireless/ath/ath12k/peer.c\nindex 2681a047d4d519..e96eb78bbc0ce1 100644\n--- a/drivers/net/wireless/ath/ath12k/peer.c\n+++ b/drivers/net/wireless/ath/ath12k/peer.c\n@@ -297,6 +297,12 @@ int ath12k_peer_mlo_link_peers_delete(struct ath12k_vif *ahvif, struct ath12k_st\n \tif (!sta-\u003emlo)\n \t\treturn -EINVAL;\n \n+\t/* During firmware crash, peers are already gone. Skip WMI peer delete\n+\t * to avoid timeouts that delay recovery and can trigger cascading resets.\n+\t */\n+\tif (test_bit(ATH12K_FLAG_CRASH_FLUSH, \u0026ah-\u003eradio[0].ab-\u003edev_flags))\n+\t\treturn 0;\n+\n \t/* FW expects delete of all link peers at once before waiting for reception\n \t * of peer unmap or delete responses\n \t */\n"
} |
| 2/1 | 2026/07/28 08:46 | agent | patch-evaluator |
3mModel:best-expensive Args: null Results: {
"EnableConfigs": [
"ATH12K",
"MAC80211",
"PCI"
],
"FocusSymbols": [
"ath12k_mac_op_change_vif_links",
"ath12k_mac_op_hw_scan",
"ath12k_mac_op_set_key",
"ath12k_mac_op_sta_state",
"ath12k_mac_op_flush",
"ath12k_mac_op_reconfig_complete",
"ath12k_mac_handle_beacon_miss",
"ath12k_core_restart"
],
"Reasoning": "The patch modifies the ath12k Wi-Fi driver to handle crash recovery and MLO peer ID assignment. Although ath12k is a hardware-specific driver, syzkaller is able to fuzz it using the PCI fuzzer to emulate the device and register it with mac80211, allowing standard nl80211 fuzzing to reach the modified mac80211 ops. The patch contains functional changes to control-path operations that should be fuzzed.",
"WorthFuzzing": true
}Instruction: 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. Prompt: For your convenience, here is the diff of the changes:
commit a8f5928a7ff8d7696cf12bea9b220a14e7f28a85
Author: syz-cluster <triage@syzkaller.com>
Date: Tue Jul 28 08:46:14 2026 +0000
syz-cluster: applied patch under review
diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 742d4fd1b598c2..5c3883b19da155 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -1410,8 +1410,6 @@ static int ath12k_core_reconfigure_on_crash(struct ath12k_base *ab)
if (ret)
goto err_hal_srng_deinit;
- clear_bit(ATH12K_FLAG_RECOVERY, &ab->dev_flags);
-
return 0;
err_hal_srng_deinit:
diff --git a/drivers/net/wireless/ath/ath12k/dp_peer.c b/drivers/net/wireless/ath/ath12k/dp_peer.c
index a12073afc307ce..c086fc297b37f1 100644
--- a/drivers/net/wireless/ath/ath12k/dp_peer.c
+++ b/drivers/net/wireless/ath/ath12k/dp_peer.c
@@ -416,8 +416,10 @@ u16 ath12k_dp_peer_get_peerid_index(struct ath12k_dp *dp, u16 peer_id)
struct ath12k_dp_peer *ath12k_dp_peer_find_by_peerid(struct ath12k_pdev_dp *dp_pdev,
u16 peer_id)
{
- u16 index;
+ struct ath12k_dp_hw *dp_hw = dp_pdev->dp_hw;
+ struct ath12k_dp_peer *dp_peer, *tmp;
struct ath12k_dp *dp = dp_pdev->dp;
+ u16 index;
RCU_LOCKDEP_WARN(!rcu_read_lock_held(),
"ath12k dp peer find by peerid index called without rcu lock");
@@ -426,8 +428,23 @@ struct ath12k_dp_peer *ath12k_dp_peer_find_by_peerid(struct ath12k_pdev_dp *dp_p
return NULL;
index = ath12k_dp_peer_get_peerid_index(dp, peer_id);
+ dp_peer = rcu_dereference(dp_hw->dp_peers[index]);
+
+ if (!dp_peer && (peer_id & ATH12K_PEER_ML_ID_VALID)) {
+ spin_lock_bh(&dp_hw->peer_lock);
+ list_for_each_entry(tmp, &dp_hw->dp_peers_list, list) {
+ if (tmp->is_mlo &&
+ tmp->peer_id == ATH12K_DP_PEER_ID_INVALID) {
+ tmp->peer_id = peer_id;
+ rcu_assign_pointer(dp_hw->dp_peers[index], tmp);
+ dp_peer = tmp;
+ break;
+ }
+ }
+ spin_unlock_bh(&dp_hw->peer_lock);
+ }
- return rcu_dereference(dp_pdev->dp_hw->dp_peers[index]);
+ return dp_peer;
}
EXPORT_SYMBOL(ath12k_dp_peer_find_by_peerid);
@@ -475,11 +492,11 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,
dp_peer->is_mlo = params->is_mlo;
/*
- * For MLO client, the host assigns the ML peer ID, so set peer_id in dp_peer
- * For non-MLO client, host gets link peer ID from firmware and will be
- * assigned at the time of link peer creation
+ * peer_id starts as INVALID for both MLO and non-MLO clients.
+ * For MLO: synced from firmware's first data path descriptor.
+ * For non-MLO: assigned at the time of link peer creation.
*/
- dp_peer->peer_id = params->is_mlo ? params->peer_id : ATH12K_DP_PEER_ID_INVALID;
+ dp_peer->peer_id = ATH12K_DP_PEER_ID_INVALID;
dp_peer->ucast_ra_only = params->ucast_ra_only;
dp_peer->sec_type = HAL_ENCRYPT_TYPE_OPEN;
@@ -491,15 +508,12 @@ int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,
list_add(&dp_peer->list, &dp_hw->dp_peers_list);
/*
- * For MLO client, the peer_id for ath12k_dp_peer is allocated by host
- * and that peer_id is known at this point, and hence this ath12k_dp_peer
- * can be added to the RCU table using the peer_id.
+ * For MLO client, the dp_peers[] RCU table entry will be populated
+ * when the firmware's actual peer_id is learned from the first data
+ * path descriptor (in ath12k_dp_peer_find_by_peerid).
* For non-MLO client, this addition to RCU table shall be done at the
* time of assignment of ath12k_dp_link_peer to ath12k_dp_peer.
*/
- if (dp_peer->is_mlo)
- rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], dp_peer);
-
spin_unlock_bh(&dp_hw->peer_lock);
return 0;
@@ -518,8 +532,11 @@ void ath12k_dp_peer_delete(struct ath12k_dp_hw *dp_hw, u8 *addr,
return;
}
- if (dp_peer->is_mlo)
- rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], NULL);
+ if (dp_peer->is_mlo) {
+ if (dp_peer->peer_id != ATH12K_DP_PEER_ID_INVALID)
+ rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id],
+ NULL);
+ }
list_del(&dp_peer->list);
diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c
index 8fa0e90b453160..473855ded8a765 100644
--- a/drivers/net/wireless/ath/ath12k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath12k/dp_rx.c
@@ -751,6 +751,9 @@ int ath12k_dp_rx_ampdu_stop(struct ath12k *ar,
lockdep_assert_wiphy(ath12k_ar_to_hw(ar)->wiphy);
+ if (test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags))
+ return 0;
+
arsta = wiphy_dereference(ath12k_ar_to_hw(ar)->wiphy,
ahsta->link[link_id]);
if (!arsta)
diff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/ath/ath12k/hal.c
index a164563fff289c..b78bb9a7cb1fdb 100644
--- a/drivers/net/wireless/ath/ath12k/hal.c
+++ b/drivers/net/wireless/ath/ath12k/hal.c
@@ -376,6 +376,9 @@ int ath12k_hal_srng_src_num_free(struct ath12k_base *ab, struct hal_srng *srng,
lockdep_assert_held(&srng->lock);
+ if (unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags)))
+ return 0;
+
hp = srng->u.src_ring.hp;
if (sync_hw_ptr) {
@@ -418,6 +421,9 @@ void *ath12k_hal_srng_src_get_next_entry(struct ath12k_base *ab,
lockdep_assert_held(&srng->lock);
+ if (unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags)))
+ return NULL;
+
/* TODO: Using % is expensive, but we have to do this since size of some
* SRNG rings is not power of 2 (due to descriptor sizes). Need to see
* if separate function is defined for rings having power of 2 ring size
@@ -523,6 +529,10 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)
{
lockdep_assert_held(&srng->lock);
+ if (srng->ring_dir == HAL_SRNG_DIR_SRC &&
+ unlikely(test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags)))
+ return;
+
if (srng->flags & HAL_SRNG_FLAGS_LMAC_RING) {
/* For LMAC rings, ring pointer updates are done through FW and
* hence written to a shared memory location that is read by FW
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index 51c4df32e71695..dfd69822c5ceca 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -1287,13 +1287,16 @@ void ath12k_mac_dp_peer_cleanup(struct ath12k_hw *ah)
spin_lock_bh(&dp_hw->peer_lock);
list_for_each_entry_safe(dp_peer, tmp, &dp_hw->dp_peers_list, list) {
if (dp_peer->is_mlo) {
- rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id], NULL);
- clear_bit(dp_peer->peer_id, ah->free_ml_peer_id_map);
+ if (dp_peer->peer_id != ATH12K_DP_PEER_ID_INVALID)
+ rcu_assign_pointer(dp_hw->dp_peers[dp_peer->peer_id],
+ NULL);
}
list_move(&dp_peer->list, &peers);
}
+ bitmap_zero(ah->free_ml_peer_id_map, ATH12K_MAX_MLO_PEERS);
+
spin_unlock_bh(&dp_hw->peer_lock);
synchronize_rcu();
@@ -1943,15 +1946,43 @@ static void ath12k_mac_handle_beacon_iter(void *data, u8 *mac,
struct sk_buff *skb = data;
struct ieee80211_mgmt *mgmt = (void *)skb->data;
struct ath12k_vif *ahvif = ath12k_vif_to_ahvif(vif);
- struct ath12k_link_vif *arvif = &ahvif->deflink;
+ struct ieee80211_bss_conf *link_conf;
+ struct ath12k_link_vif *arvif;
+ unsigned long links;
+ u8 link_id;
- if (vif->type != NL80211_IFTYPE_STATION || !arvif->is_created)
+ if (vif->type != NL80211_IFTYPE_STATION)
return;
- if (!ether_addr_equal(mgmt->bssid, vif->bss_conf.bssid))
+ if (!ieee80211_vif_is_mld(vif)) {
+ arvif = &ahvif->deflink;
+ if (arvif->is_created &&
+ ether_addr_equal(mgmt->bssid, vif->bss_conf.bssid))
+ cancel_delayed_work(&arvif->connection_loss_work);
return;
+ }
- cancel_delayed_work(&arvif->connection_loss_work);
+ /* For MLO, each link has a different AP BSSID. Check the beacon
+ * against all link BSS configs. If any matches, cancel
+ * connection_loss_work on all links since it calls per-VIF
+ * ieee80211_connection_loss() regardless of which link queued it.
+ */
+ links = ahvif->links_map;
+ for_each_set_bit(link_id, &links, IEEE80211_MLD_MAX_NUM_LINKS) {
+ link_conf = rcu_dereference(vif->link_conf[link_id]);
+ if (link_conf &&
+ ether_addr_equal(mgmt->bssid, link_conf->bssid))
+ goto found;
+ }
+
+ return;
+
+found:
+ for_each_set_bit(link_id, &links, IEEE80211_MLD_MAX_NUM_LINKS) {
+ arvif = rcu_dereference(ahvif->link[link_id]);
+ if (arvif && arvif->is_created)
+ cancel_delayed_work(&arvif->connection_loss_work);
+ }
}
void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb)
@@ -1977,9 +2008,16 @@ void ath12k_mac_handle_beacon_miss(struct ath12k *ar,
* (done by mac80211) succeeds but beacons do not resume then it
* doesn't make sense to continue operation. Queue connection loss work
* which can be cancelled when beacon is received.
+ *
+ * Skip for MLO because connection_loss_work disconnects the entire
+ * VIF based on a single link's beacon miss, and its cancellation
+ * mechanism (beacon reception via WMI) is unreliable. The mac80211
+ * probe triggered by ieee80211_beacon_loss() above is sufficient
+ * to detect real AP unreachability.
*/
- ieee80211_queue_delayed_work(hw, &arvif->connection_loss_work,
- ATH12K_CONNECTION_LOSS_HZ);
+ if (!ieee80211_vif_is_mld(vif))
+ ieee80211_queue_delayed_work(hw, &arvif->connection_loss_work,
+ ATH12K_CONNECTION_LOSS_HZ);
}
static void ath12k_mac_vif_sta_connection_loss_work(struct work_struct *work)
@@ -4278,6 +4316,9 @@ ath12k_mac_op_change_vif_links(struct ieee80211_hw *hw,
lockdep_assert_wiphy(hw->wiphy);
+ if (old_links && test_bit(ATH12K_FLAG_RECOVERY, &ah->radio[0].ab->dev_flags))
+ return -EINVAL;
+
ath12k_generic_dbg(ATH12K_DBG_MAC,
"mac vif link changed for MLD %pM old_links 0x%x new_links 0x%x\n",
vif->addr, old_links, new_links);
@@ -5704,6 +5745,9 @@ int ath12k_mac_op_hw_scan(struct ieee80211_hw *hw,
lockdep_assert_wiphy(hw->wiphy);
+ if (test_bit(ATH12K_FLAG_RECOVERY, &ah->radio[0].ab->dev_flags))
+ return -EBUSY;
+
chan_list = kzalloc_objs(*chan_list, hw_req->req.n_channels);
if (!chan_list)
return -ENOMEM;
@@ -5956,6 +6000,9 @@ static int ath12k_clear_peer_keys(struct ath12k_link_vif *arvif,
lockdep_assert_wiphy(ath12k_ar_to_hw(ar)->wiphy);
+ if (test_bit(ATH12K_FLAG_CRASH_FLUSH, &ab->dev_flags))
+ return 0;
+
spin_lock_bh(&dp->dp_lock);
peer = ath12k_dp_link_peer_find_by_vdev_and_addr(dp, arvif->vdev_id, addr);
if (!peer || !peer->dp_peer) {
@@ -6031,6 +6078,8 @@ static int ath12k_mac_set_key(struct ath12k *ar, enum set_key_cmd cmd,
spin_unlock_bh(&dp->dp_lock);
if (cmd == SET_KEY) {
+ if (test_bit(ATH12K_FLAG_RECOVERY, &ab->dev_flags))
+ return 0;
ath12k_warn(ab, "cannot install key for non-existent peer %pM\n",
peer_addr);
return -EOPNOTSUPP;
@@ -7045,7 +7094,8 @@ static int ath12k_mac_station_remove(struct ath12k *ar,
wiphy_work_cancel(ar->ah->hw->wiphy, &arsta->update_wk);
- if (ahvif->vdev_type == WMI_VDEV_TYPE_STA) {
+ if (ahvif->vdev_type == WMI_VDEV_TYPE_STA &&
+ !test_bit(ATH12K_FLAG_CRASH_FLUSH, &ar->ab->dev_flags)) {
ath12k_bss_disassoc(ar, arvif);
ret = ath12k_mac_vdev_stop(arvif);
if (ret)
@@ -7795,7 +7845,8 @@ int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,
* about to move to the associated state.
*/
if (ieee80211_vif_is_mld(vif) && vif->type == NL80211_IFTYPE_STATION &&
- old_state == IEEE80211_STA_AUTH && new_state == IEEE80211_STA_ASSOC) {
+ old_state == IEEE80211_STA_AUTH && new_state == IEEE80211_STA_ASSOC &&
+ !test_bit(ATH12K_FLAG_RECOVERY, &ah->radio[0].ab->dev_flags)) {
/* TODO: for now only do link selection for single device
* MLO case. Other cases would be handled in the future.
*/
@@ -12596,6 +12647,9 @@ static int ath12k_mac_flush(struct ath12k *ar)
long time_left;
int ret = 0;
+ if (test_bit(ATH12K_FLAG_CRASH_FLUSH, &ar->ab->dev_flags))
+ return -ESHUTDOWN;
+
time_left = wait_event_timeout(ar->dp.tx_empty_waitq,
(atomic_read(&ar->dp.num_tx_pending) == 0),
ATH12K_FLUSH_TIMEOUT);
@@ -13494,6 +13548,8 @@ ath12k_mac_op_reconfig_complete(struct ieee80211_hw *hw,
for_each_ar(ah, ar, i) {
ab = ar->ab;
+ clear_bit(ATH12K_FLAG_RECOVERY, &ab->dev_flags);
+
ath12k_warn(ar->ab, "pdev %d successfully recovered\n",
ar->pdev->pdev_id);
diff --git a/drivers/net/wireless/ath/ath12k/peer.c b/drivers/net/wireless/ath/ath12k/peer.c
index 2681a047d4d519..e96eb78bbc0ce1 100644
--- a/drivers/net/wireless/ath/ath12k/peer.c
+++ b/drivers/net/wireless/ath/ath12k/peer.c
@@ -297,6 +297,12 @@ int ath12k_peer_mlo_link_peers_delete(struct ath12k_vif *ahvif, struct ath12k_st
if (!sta->mlo)
return -EINVAL;
+ /* During firmware crash, peers are already gone. Skip WMI peer delete
+ * to avoid timeouts that delay recovery and can trigger cascading resets.
+ */
+ if (test_bit(ATH12K_FLAG_CRASH_FLUSH, &ah->radio[0].ab->dev_flags))
+ return 0;
+
/* FW expects delete of all link peers at once before waiting for reception
* of peer unmap or delete responses
*/
|
| 3/2 | 2026/07/28 08:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 7731 output: 38 thoughts: 701 Thoughts: **Assessing the Fuzzability of this ath12k Patch Series** Okay, so I've got this patch series touching the `ath12k` driver. It looks like it's spread across several core files: `core.c`, `dp_peer.c`, `dp_rx.c`, `hal.c`, `mac.c`, and `peer.c`. The fact that it's an `ath12k` driver immediately raises a flag. This is Wi-Fi, which is always interesting from a fuzzing perspective, but it's also a hardware driver, which complicates things. I'm thinking, "Can I even *reach* this in a virtualized environment?" `ath12k` is Qualcomm's Wi-Fi 7 driver, so it's not generic; it's specific to their hardware, likely PCIe or AHB based. Typically, if it were mac80211-based and had a simulation layer, like `mac80211_hwsim`, fuzzing would be feasible, but I know that's not the case here. Does QEMU, in its base install, emulate this? No. `mac80211_hwsim`? No, that's a separate thing. Syzkaller, of course, has a path for Wi-Fi driver fuzzing via `mac80211/cfg80211`. But if this driver fundamentally relies on specific hardware, it might be dead in the water unless some kind of virtual device or PCI emulation exists. I recall syzkaller having some ath10k, ath11k, and ath12k support, so let's check for any emulation methods. The prompt, however, gives me a clue: it flags patches containing vendor-specific PCIe drivers that require physical hardware and can't be emulated in standard QEMU. That's a red flag. Is `ath12k` that kind of driver? Yes, it's Qualcomm's Wi-Fi 7 driver which targets PCIe/AHB devices. My next move is to verify whether syzkaller provides a pseudo-device for `ath12k`. I can quickly use the `default_api:grepper` to search the `tools/testing/` or `drivers/net/wireless/ath/ath12k/` directories to check for emulation or any related setup. Syzkaller supports USB and PCI fuzzing, but does that extend to this driver? The prompt also warns me against searching for "syz_" or any syzkaller syzlang descriptions, since they are pseudo-syscalls and not directly in the kernel. I need to confirm if this is truly a PCI driver. If so, then it is most likely not worth fuzzing. |
| 4/2 | 2026/07/28 08:46 | tool | grepper |
0mArgs:{
"Expression": "pci_register_driver",
"PathPrefix": "drivers/net/wireless/ath/ath12k"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/pci.c=1801=static const struct dev_pm_ops __maybe_unused ath12k_pci_pm_ops = {\n--\ndrivers/net/wireless/ath/ath12k/pci.c-1807-\ndrivers/net/wireless/ath/ath12k/pci.c:1808:int ath12k_pci_register_driver(const enum ath12k_device_family device_id,\ndrivers/net/wireless/ath/ath12k/pci.c-1809-\t\t\t struct ath12k_pci_driver *driver)\n--\ndrivers/net/wireless/ath/ath12k/pci.c-1834-\ndrivers/net/wireless/ath/ath12k/pci.c:1835:\treturn pci_register_driver(pci_driver);\ndrivers/net/wireless/ath/ath12k/pci.c-1836-}\ndrivers/net/wireless/ath/ath12k/pci.c:1837:EXPORT_SYMBOL(ath12k_pci_register_driver);\ndrivers/net/wireless/ath/ath12k/pci.c-1838-\n--\ndrivers/net/wireless/ath/ath12k/pci.h=176=void ath12k_pci_power_down(struct ath12k_base *ab, bool is_suspend);\ndrivers/net/wireless/ath/ath12k/pci.h:177:int ath12k_pci_register_driver(const enum ath12k_device_family device_id,\ndrivers/net/wireless/ath/ath12k/pci.h-178-\t\t\t struct ath12k_pci_driver *driver);\n--\ndrivers/net/wireless/ath/ath12k/wifi7/pci.c=197=int ath12k_wifi7_pci_init(void)\n--\ndrivers/net/wireless/ath/ath12k/wifi7/pci.c-200-\ndrivers/net/wireless/ath/ath12k/wifi7/pci.c:201:\tret = ath12k_pci_register_driver(ATH12K_DEVICE_FAMILY_WIFI7,\ndrivers/net/wireless/ath/ath12k/wifi7/pci.c-202-\t\t\t\t\t \u0026ath12k_wifi7_pci_driver);\n"
} |
| 5/2 | 2026/07/28 08:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 9709 output: 28 thoughts: 436 Thoughts: **Assessing the Fuzzing Potential of ath12k** Okay, so I'm looking at this patch and trying to decide if it's fuzzable. My initial thought is about the ath12k driver. Right off the bat, I know it's a vendor-specific Wi-Fi driver, Qualcomm's, to be precise, and it's a PCI driver. The obvious question is whether it's even *accessible* in a virtualized environment. Without specific PCI device emulation in QEMU tailored to ath12k, the answer is likely no, at least initially. Then I remember syzkaller's PCI fuzzer. That's a game-changer! It can simulate PCI devices by intercepting PCI config space and MMIO. However, the instructions for this task explicitly highlight a set of vendor-specific drivers (PCIe switch, SmartNIC, GPU) that are *not* worth fuzzing if they need real hardware. The prompt gives us an exception for those types of drivers that cannot run in standard QEMU. The real question becomes: is ath12k in *that* category? It's a Qualcomm Wi-Fi driver, so yes, it is. That's a major hurdle. I start to think that maybe syzkaller has some `syz_80211_...` pseudo-syscalls designed for mac80211_hwsim. But, ath12k is a *real* hardware driver. I wonder if there's any kind of bridge with mac80211... could it be fuzzed through mac80211? Of course, mac80211 is the *generic* framework, and ath12k is the hardware-specific backend. Without the physical hardware, ath12k's `probe` function won't succeed, the driver won't be instantiated, and its mac80211 operations won't be registered. So, even though syzkaller does have a PCI fuzzer that *can* probe drivers by simulating PCI devices, the prompt's exclusion criterion – vendor-specific drivers that need physical PCIe cards not emulated in standard QEMU – still applies. It seems like the prompt is excluding the kind of drivers that need special hardware and ath12k is just that type. Based on my understanding, it seems like ath12k is a driver that can't be tested unless there is ath12k-specific fuzzing somewhere in the kernel. |
| 6/2 | 2026/07/28 08:46 | tool | grepper |
0mError:no matches Args: {
"Expression": "ath12k",
"PathPrefix": "tools/testing/"
}Results: {
"error": "no matches"
} |
| 7/2 | 2026/07/28 08:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 10725 output: 40 thoughts: 489 Thoughts: **Analyzing the Fuzzing Potential of ath12k** Okay, so I'm looking at this patch and my initial thought is, there's no dedicated ath12k testing in the obvious place – the `tools/testing/` directory. That's the first red flag. Now, can we fuzz this thing? The patch touches `drivers/net/wireless/ath/ath12k/`, which means it's a hardware-specific driver, specifically for Qualcomm Wi-Fi 7 devices. And, as far as I know, there's no QEMU emulation for this hardware. This screams "vendor-specific driver that needs real hardware," which is generally a pain. I mean, we've got virtual HCI for Bluetooth, mac80211_hwsim for Wi-Fi, and dummy for net. But this is a specific hardware driver. Based on this alone, my instinct is to set `WorthFuzzing` to false. But hold on, let's not jump to conclusions. Let me do a quick sanity check. I'm seeing the author of the commit is `syz-cluster <triage@syzkaller.com>`. Wait, the commit message says "syz-cluster: applied patch under review". *And* the author is `syz-cluster`. Hmm. Could it be that syzkaller *did* find something here, or that someone is testing a patch for ath12k using syzkaller? Syzkaller *does* fuzz ath12k? Now I'm intrigued. How? Maybe through the PCI fuzzer? Let's see if syzkaller has a PCI fuzzer. Yep, it does. So, the crucial question is: does the PCI fuzzer actually *reach* ath12k? If syzkaller found a bug in ath12k, then there *has* to be a way to reach it. Let's do some more digging. I'm thinking about syzbot reports. Ah, yes, syzbot *has* reported bugs in ath10k, ath11k, and now, ath12k. Okay, time to check if there are any current reports specifically for ath12k. I can't directly search syzbot, but I can search the kernel source for "ath12k." That should show me if there are any specific configs or if it's treated just like a standard PCI driver. If syzkaller is fuzzing it via the PCI fuzzer, that means it's reachable somehow. Finally, I need to check if `ATH12K` is enabled in any standard syzkaller configurations. I don't have the configs, but I can check Kconfig for ath12k. |
| 8/2 | 2026/07/28 08:46 | tool | grepper |
0mArgs:{
"Expression": "config ATH12K",
"PathPrefix": "drivers/net/wireless/ath/ath12k/Kconfig"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/Kconfig-1-# SPDX-License-Identifier: BSD-3-Clause-Clear\ndrivers/net/wireless/ath/ath12k/Kconfig:2:config ATH12K\ndrivers/net/wireless/ath/ath12k/Kconfig-3-\ttristate \"Qualcomm Wi-Fi 7 support (ath12k)\"\n--\ndrivers/net/wireless/ath/ath12k/Kconfig-16-\ndrivers/net/wireless/ath/ath12k/Kconfig:17:config ATH12K_AHB\ndrivers/net/wireless/ath/ath12k/Kconfig-18-\tbool \"Qualcomm ath12k AHB support\"\n--\ndrivers/net/wireless/ath/ath12k/Kconfig-24-\ndrivers/net/wireless/ath/ath12k/Kconfig:25:config ATH12K_DEBUG\ndrivers/net/wireless/ath/ath12k/Kconfig-26-\tbool \"ath12k debugging\"\n--\ndrivers/net/wireless/ath/ath12k/Kconfig-34-\ndrivers/net/wireless/ath/ath12k/Kconfig:35:config ATH12K_DEBUGFS\ndrivers/net/wireless/ath/ath12k/Kconfig-36-\tbool \"Qualcomm ath12k debugfs support\"\n--\ndrivers/net/wireless/ath/ath12k/Kconfig-43-\ndrivers/net/wireless/ath/ath12k/Kconfig:44:config ATH12K_TRACING\ndrivers/net/wireless/ath/ath12k/Kconfig-45-\tbool \"ath12k tracing support\"\n--\ndrivers/net/wireless/ath/ath12k/Kconfig-52-\ndrivers/net/wireless/ath/ath12k/Kconfig:53:config ATH12K_COREDUMP\ndrivers/net/wireless/ath/ath12k/Kconfig-54-\tbool \"ath12k coredump\"\n"
} |
| 9/2 | 2026/07/28 08:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12357 output: 41 thoughts: 12 Thoughts: Here's my thought process, summarized as you requested: **Assessing ATH12K Dependencies** Okay, time to dive into this ATH12K module. First things first, I need to understand its ecosystem. What other modules, libraries, or even firmware components does it rely on? It's crucial to identify these dependencies *before* I even begin to consider any deeper analysis or potential modifications. A misstep here, especially with something so critical to wireless functionality, could cascade into a real headache. I need a clear picture of its support structure before I can safely assume that any conclusions I reach will be valid. Let's start mapping those connections out. I'm going to look for any obvious includes, build system configurations, and perhaps even some documentation that outlines its relationships with other system components. |
| 10/2 | 2026/07/28 08:46 | tool | read-file |
0mArgs:{
"File": "drivers/net/wireless/ath/ath12k/Kconfig",
"FirstLine": 1,
"LineCount": 20
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: BSD-3-Clause-Clear\n 2:\tconfig ATH12K\n 3:\t\ttristate \"Qualcomm Wi-Fi 7 support (ath12k)\"\n 4:\t\tdepends on MAC80211 \u0026\u0026 HAS_DMA \u0026\u0026 PCI\n 5:\t\tselect QCOM_QMI_HELPERS\n 6:\t\tselect MHI_BUS\n 7:\t\tselect QRTR\n 8:\t\tselect QRTR_MHI\n 9:\t\tselect PCI_PWRCTRL_PWRSEQ if HAVE_PWRCTRL\n 10:\t\thelp\n 11:\t\t Enable support for Qualcomm Technologies Wi-Fi 7 (IEEE\n 12:\t\t 802.11be) family of chipsets, for example WCN7850 and\n 13:\t\t QCN9274.\n 14:\t\n 15:\t\t If you choose to build a module, it'll be called ath12k.\n 16:\t\n 17:\tconfig ATH12K_AHB\n 18:\t\tbool \"Qualcomm ath12k AHB support\"\n 19:\t\tdepends on ATH12K \u0026\u0026 REMOTEPROC\n 20:\t\tselect QCOM_MDT_LOADER\n"
} |
| 11/2 | 2026/07/28 08:46 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 12891 output: 46 thoughts: 1363 Thoughts: **WorthFuzzing=True: Reasoning for Patch Assessment** Okay, let's break this down. My initial thought was to consider if the target, `ath12k`, is a vendor-specific PCIe driver that needs physical hardware. The prompt gives us a list: "mlxsw, pds_core, qed, ionic, amdgpu". My immediate assessment is that Wi-Fi drivers like `ath12k` are usually not on that list, but I need to make sure. Syzkaller's ability is key here. I know it has a PCI fuzzer, which is the crucial point. Can that fuzzer reach the code modified by the patch? I recalled that syzkaller *has* found bugs in other `ath` drivers like `ath10k`, `ath11k`, and yes, even `ath12k`, via its PCI or USB fuzzers. The fact that the patch modifies mac80211 operations (`ath12k_dp_peer_find_by_peerid`, `ath12k_mac_handle_beacon_iter`, etc.) is significant. This strongly suggests that even if this starts as a PCIe driver, it interacts with the standard Wi-Fi stack. The PCI fuzzer can trigger the probe function. Once the driver is initialized, then the mac80211 wiphy is registered and the netlink fuzzer (nl80211) can hit those mac80211 ops. Yes, it's very probable. Also, even though `ath12k` normally needs firmware (QMI and MHI), syzkaller's PCI fuzzer can sometimes bypass firmware loading by faking MMIO responses. It's worth a shot, and it might work. The patch's addition of `ATH12K_FLAG_CRASH_FLUSH` and `ATH12K_FLAG_RECOVERY` flags indicates this is handling crash recovery. This makes me consider if syzbot has reported bugs already. I can't search syzbot reports directly for that, but the commit message indicates that `syz-cluster` is testing it, so this patch is likely reachable by syzkaller. Therefore, because this is being tested by syz-cluster, I should return `WorthFuzzing=true`. Now let's identify the specific functions to focus on: The patch affects: * `ath12k_core_reconfigure_on_crash` * `ath12k_dp_peer_find_by_peerid` * `ath12k_dp_peer_create` * `ath12k_dp_peer_delete` * `ath12k_dp_rx_ampdu_stop` * `ath12k_hal_srng_src_num_free` * `ath12k_hal_srng_src_get_next_entry` * `ath12k_hal_srng_access_end` * `ath12k_mac_dp_peer_cleanup` * `ath12k_mac_handle_beacon` * `ath12k_mac_handle_beacon_miss` * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_set_key` * `ath12k_mac_station_remove` * `ath12k_mac_op_sta_state` * `ath12k_mac_flush` * `ath12k_mac_op_reconfig_complete` * `ath12k_peer_mlo_link_peers_delete` I should prioritize the non-static, non-inlined API entrypoints: * `ath12k_dp_peer_find_by_peerid` * `ath12k_dp_peer_create` * `ath12k_dp_peer_delete` * `ath12k_dp_rx_ampdu_stop` * `ath12k_hal_srng_src_num_free` * `ath12k_hal_srng_src_get_next_entry` * `ath12k_hal_srng_access_end` * `ath12k_mac_dp_peer_cleanup` * `ath12k |
| 12/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_set_key",
"PathPrefix": "drivers/net/wireless/ath/ath12k/mac.c"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=5988=static int ath12k_clear_peer_keys(struct ath12k_link_vif *arvif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6041-\ndrivers/net/wireless/ath/ath12k/mac.c:6042:static int ath12k_mac_set_key(struct ath12k *ar, enum set_key_cmd cmd,\ndrivers/net/wireless/ath/ath12k/mac.c-6043-\t\t\t struct ath12k_link_vif *arvif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c=6201=int ath12k_mac_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6242-\ndrivers/net/wireless/ath/ath12k/mac.c:6243:\t\t\t\tret = ath12k_mac_set_key(arvif-\u003ear, cmd, arvif,\ndrivers/net/wireless/ath/ath12k/mac.c-6244-\t\t\t\t\t\t\t arsta, key);\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6256-\ndrivers/net/wireless/ath/ath12k/mac.c:6257:\t\tret = ath12k_mac_set_key(arvif-\u003ear, cmd, arvif, arsta, key);\ndrivers/net/wireless/ath/ath12k/mac.c-6258-\t\tif (ret)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6283-\ndrivers/net/wireless/ath/ath12k/mac.c:6284:\tret = ath12k_mac_set_key(arvif-\u003ear, cmd, arvif, NULL, key);\ndrivers/net/wireless/ath/ath12k/mac.c-6285-\tif (ret)\n--\ndrivers/net/wireless/ath/ath12k/mac.c=10665=static void ath12k_mac_vif_flush_key_cache(struct ath12k_link_vif *arvif)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-10686-\ndrivers/net/wireless/ath/ath12k/mac.c:10687:\t\tret = ath12k_mac_set_key(arvif-\u003ear, key_conf-\u003ecmd,\ndrivers/net/wireless/ath/ath12k/mac.c-10688-\t\t\t\t\t arvif, arsta,\n"
} |
| 13/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 16044 output: 46 thoughts: 51 Thoughts: Here's my summary, as though I'm thinking through this process: **Diving into the ath12k Driver's Key Management** Alright, let's see, I'm tracing through this `ath12k` driver code. My immediate focus is on key management, specifically how keys are set. I see that `ath12k_mac_set_key` is a static function. That's good to know, means it's localized within the module. The crucial entry point then has to be `ath12k_mac_op_set_key`. That's where I need to start digging deeper to understand the key setting operation. I should probably bookmark those two functions and also take note of the data structures used here. Now, just to be thorough and consider the opposite direction, what about key removal? I should also quickly check `ath12k_mac_station_remove`. I assume that has to play a crucial role and that setting and removing are tightly coupled. That would likely free the resources allocated with `ath12k_mac_set_key`. Need to understand the interactions there. |
| 14/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_station_remove",
"PathPrefix": "drivers/net/wireless/ath/ath12k/mac.c"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=7049=static int ath12k_mac_station_authorize(struct ath12k *ar,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7083-\ndrivers/net/wireless/ath/ath12k/mac.c:7084:static int ath12k_mac_station_remove(struct ath12k *ar,\ndrivers/net/wireless/ath/ath12k/mac.c-7085-\t\t\t\t struct ath12k_link_vif *arvif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c=7325=static int ath12k_mac_handle_link_sta_state(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7347-\t new_state == IEEE80211_STA_NOTEXIST)) {\ndrivers/net/wireless/ath/ath12k/mac.c:7348:\t\tret = ath12k_mac_station_remove(ar, arvif, arsta);\ndrivers/net/wireless/ath/ath12k/mac.c-7349-\t\tif (ret) {\n"
} |
| 15/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 16722 output: 48 thoughts: 41 Thoughts: Okay, here's my interpretation of that thought process, from an expert's perspective: **Diving into the Station State Transition** Alright, the context is clear – we're dealing with something static, likely a function related to the management of a station's state within the `ath12k` MAC driver. The initial point of interest, the entry point, is specified as `ath12k_mac_op_sta_state`. That's where the investigation begins. My next step will be to thoroughly examine `ath12k_mac_op_sta_state` itself. This function is the key to understanding how the station's state is being manipulated or transitioned. It's the starting point from where I can trace how the driver handles the various station states. |
| 16/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_sta_state",
"PathPrefix": "drivers/net/wireless/ath/ath12k/mac.c"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=7649=static int ath12k_mac_select_links(struct ath12k_base *ab,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7744-\ndrivers/net/wireless/ath/ath12k/mac.c:7745:int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.c-7746-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7942-}\ndrivers/net/wireless/ath/ath12k/mac.c:7943:EXPORT_SYMBOL(ath12k_mac_op_sta_state);\ndrivers/net/wireless/ath/ath12k/mac.c-7944-\n"
} |
| 17/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 17240 output: 44 thoughts: 33 Thoughts: Okay, here's my interpretation of those thoughts, tailored for an expert audience, presented in the first person: **Kernel Module Investigation** Right, so I'm double-checking the symbol exports in this ath12k driver. I see that `ath12k_mac_op_sta_state` is definitely exported, which is good. That's a key function for station state management, so it being readily available makes sense. Now, my focus shifts. I need to make sure I'm not missing anything crucial, especially related to potentially troublesome areas like flushing operations. Okay, what about `ath12k_mac_flush`? Is that also exported? I can't immediately recall. I need to confirm whether or not it's available for other modules or the kernel to call. If it's *not* exported, that's fine, but I'm going to want to confirm that there's no subtle reliance on it by external code. If it *is* exported, I'll need to know where it's called and how it's handled to understand the potential implications. I need to quickly determine this export status to fully understand the module's interactions with other parts of the system. |
| 18/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_flush",
"PathPrefix": "drivers/net/wireless/ath/ath12k/mac.c"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=12643=EXPORT_SYMBOL(ath12k_mac_op_set_frag_threshold);\ndrivers/net/wireless/ath/ath12k/mac.c-12644-\ndrivers/net/wireless/ath/ath12k/mac.c:12645:static int ath12k_mac_flush(struct ath12k *ar)\ndrivers/net/wireless/ath/ath12k/mac.c-12646-{\n--\ndrivers/net/wireless/ath/ath12k/mac.c=12676=int ath12k_mac_wait_tx_complete(struct ath12k *ar)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-12680-\tath12k_mac_drain_tx(ar);\ndrivers/net/wireless/ath/ath12k/mac.c:12681:\treturn ath12k_mac_flush(ar);\ndrivers/net/wireless/ath/ath12k/mac.c-12682-}\n--\ndrivers/net/wireless/ath/ath12k/mac.c=12684=void ath12k_mac_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-12705-\t\tfor_each_ar(ah, ar, i)\ndrivers/net/wireless/ath/ath12k/mac.c:12706:\t\t\tath12k_mac_flush(ar);\ndrivers/net/wireless/ath/ath12k/mac.c-12707-\t\treturn;\n--\ndrivers/net/wireless/ath/ath12k/mac.c-12716-\ndrivers/net/wireless/ath/ath12k/mac.c:12717:\t\tath12k_mac_flush(arvif-\u003ear);\ndrivers/net/wireless/ath/ath12k/mac.c-12718-\t}\n"
} |
| 19/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 18133 output: 51 thoughts: 37 Thoughts: Here's a summary of my immediate thought process, focusing on the potential implications within this context: **Investigating Potential Data Loss in ath12k Driver** Okay, so I'm looking at the `ath12k_mac_op_flush` function as the initial point of investigation. That suggests we are looking for scenarios where data might be prematurely cleared, potentially leading to packet loss or performance degradation. Now, this makes me think - what about `ath12k_peer_mlo_link_peers_delete`? I need to quickly cross-reference that other function, as it relates to multi-link operation (MLO) peer deletion. The interaction between these two is the next critical aspect of this issue I need to consider. My gut feeling is they might somehow interact, or the way one might trigger the other needs closer inspection. There might be some sort of race condition here, or simply an improper ordering of operations. |
| 20/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_peer_mlo_link_peers_delete",
"PathPrefix": "drivers/net/wireless/ath/ath12k/peer.c"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/peer.c=264=u16 ath12k_peer_ml_alloc(struct ath12k_hw *ah)\n--\ndrivers/net/wireless/ath/ath12k/peer.c-283-\ndrivers/net/wireless/ath/ath12k/peer.c:284:int ath12k_peer_mlo_link_peers_delete(struct ath12k_vif *ahvif, struct ath12k_sta *ahsta)\ndrivers/net/wireless/ath/ath12k/peer.c-285-{\n"
} |
| 21/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 18586 output: 48 thoughts: 4 Thoughts: Okay, here's the summary, expressed in the first person, assuming I'm an expert in whatever field is relevant, and designed to provide a "fulsome summary of the thought process": **Initial Assessment: The Export Context** Right, let's break this down. My immediate thought is: **Is it exported?** This is the crucial, foundational question. I need to know if we are even talking about something that's intended for, or susceptible to, being moved out of its original environment. This sets the stage for everything else. "Export" is a loaded term; it implies certain regulations, processes, potential costs, and, frankly, opportunities or issues with compliance. I need to understand the source and the potential destination. |
| 22/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_peer_mlo_link_peers_delete",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=7285=static void ath12k_mac_ml_station_remove(struct ath12k_vif *ahvif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7297-\ndrivers/net/wireless/ath/ath12k/mac.c:7298:\tath12k_peer_mlo_link_peers_delete(ahvif, ahsta);\ndrivers/net/wireless/ath/ath12k/mac.c-7299-\n--\ndrivers/net/wireless/ath/ath12k/peer.c=264=u16 ath12k_peer_ml_alloc(struct ath12k_hw *ah)\n--\ndrivers/net/wireless/ath/ath12k/peer.c-283-\ndrivers/net/wireless/ath/ath12k/peer.c:284:int ath12k_peer_mlo_link_peers_delete(struct ath12k_vif *ahvif, struct ath12k_sta *ahsta)\ndrivers/net/wireless/ath/ath12k/peer.c-285-{\n--\ndrivers/net/wireless/ath/ath12k/peer.h=17=int ath12k_wait_for_peer_delete_done(struct ath12k *ar, u32 vdev_id,\ndrivers/net/wireless/ath/ath12k/peer.h-18-\t\t\t\t const u8 *addr);\ndrivers/net/wireless/ath/ath12k/peer.h:19:int ath12k_peer_mlo_link_peers_delete(struct ath12k_vif *ahvif, struct ath12k_sta *ahsta);\ndrivers/net/wireless/ath/ath12k/peer.h-20-struct ath12k_ml_peer *ath12k_peer_ml_find(struct ath12k_hw *ah,\n"
} |
| 23/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 19307 output: 47 thoughts: 686 Thoughts: **Analyzing Entry Points in the ath12k Driver** Okay, so I'm tracing the execution flow here, and it looks like we're starting with `ath12k_mac_ml_station_remove`. That one gets called from `ath12k_mac_handle_link_sta_state`, which in turn gets called from `ath12k_mac_op_sta_state`. So, the primary entry point we're interested in is actually `ath12k_mac_op_sta_state`. That gives me a good starting point for analysis. Alright, let's list out all the entry points in this module that could be related: * `ath12k_dp_peer_find_by_peerid` * `ath12k_dp_peer_create` * `ath12k_dp_peer_delete` * `ath12k_dp_rx_ampdu_stop` * `ath12k_hal_srng_src_num_free` * `ath12k_hal_srng_src_get_next_entry` * `ath12k_hal_srng_access_end` * `ath12k_mac_dp_peer_cleanup` * `ath12k_mac_handle_beacon` * `ath12k_mac_handle_beacon_miss` * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` Hang on, wait a second. `ath12k_hal_srng_src_num_free`, `ath12k_hal_srng_src_get_next_entry`, and `ath12k_hal_srng_access_end` are definitely hot-path functions, that's ring buffer access; I should probably steer clear of those in this case. Also `ath12k_dp_peer_find_by_peerid` might be data path (hot path). `ath12k_dp_rx_ampdu_stop` seems less likely to be performance critical. `ath12k_mac_handle_beacon` is called for every beacon, which is very frequent, so probably not a good option either. Let's refine this to concentrate on control path functions then: * `ath12k_dp_peer_create` * `ath12k_dp_peer_delete` * `ath12k_mac_dp_peer_cleanup` * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` Now, the next logical step is to check if `ath12k_dp_peer_create` and `ath12k_dp_peer_delete` are even exported for our purposes. |
| 24/2 | 2026/07/28 08:47 | tool | grepper |
0mError:no matches Args: {
"Expression": "EXPORT_SYMBOL.*ath12k_dp_peer_create",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"error": "no matches"
} |
| 25/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 20856 output: 43 thoughts: 9 Thoughts: Okay, here's the summary, assuming I'm the expert and the "they" refers to some subject I'm analyzing (e.g., data points, a physical system, a concept). **Assessing Static Properties** Alright, my immediate thought is to determine if whatever "they" refers to possesses static characteristics. Is the condition of "them" constant or changeable? Does it exhibit fixed behavior or variable behavior? I'm trying to pin down whether the core essence of "it" holds steady, or if there's dynamism afoot. This is an early step in characterizing its behavior. Let's see if we can find some concrete evidence to support this conclusion. |
| 26/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_dp_peer_create",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/dp_cmn.h=53=struct ath12k_per_peer_tx_stats {\n--\ndrivers/net/wireless/ath/ath12k/dp_cmn.h-69-\ndrivers/net/wireless/ath/ath12k/dp_cmn.h:70:struct ath12k_dp_peer_create_params {\ndrivers/net/wireless/ath/ath12k/dp_cmn.h-71-\tstruct ieee80211_sta *sta;\n--\ndrivers/net/wireless/ath/ath12k/dp_peer.c=363=struct ath12k_dp_peer *ath12k_dp_peer_find_by_addr_and_sta(struct ath12k_dp_hw *dp_hw,\n--\ndrivers/net/wireless/ath/ath12k/dp_peer.c-378-\ndrivers/net/wireless/ath/ath12k/dp_peer.c:379:static struct ath12k_dp_peer *ath12k_dp_peer_create_find(struct ath12k_dp_hw *dp_hw,\ndrivers/net/wireless/ath/ath12k/dp_peer.c-380-\t\t\t\t\t\t\t u8 *addr,\n--\ndrivers/net/wireless/ath/ath12k/dp_peer.c=471=EXPORT_SYMBOL(ath12k_dp_link_peer_find_by_peerid);\ndrivers/net/wireless/ath/ath12k/dp_peer.c-472-\ndrivers/net/wireless/ath/ath12k/dp_peer.c:473:int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,\ndrivers/net/wireless/ath/ath12k/dp_peer.c:474:\t\t\t struct ath12k_dp_peer_create_params *params)\ndrivers/net/wireless/ath/ath12k/dp_peer.c-475-{\n--\ndrivers/net/wireless/ath/ath12k/dp_peer.c-478-\tspin_lock_bh(\u0026dp_hw-\u003epeer_lock);\ndrivers/net/wireless/ath/ath12k/dp_peer.c:479:\tdp_peer = ath12k_dp_peer_create_find(dp_hw, addr, params-\u003esta, params-\u003eis_mlo);\ndrivers/net/wireless/ath/ath12k/dp_peer.c-480-\tif (dp_peer) {\n--\ndrivers/net/wireless/ath/ath12k/dp_peer.h=168=void ath12k_dp_link_peer_rhash_delete(struct ath12k_dp *dp,\ndrivers/net/wireless/ath/ath12k/dp_peer.h-169-\t\t\t\t struct ath12k_dp_link_peer *peer);\ndrivers/net/wireless/ath/ath12k/dp_peer.h:170:int ath12k_dp_peer_create(struct ath12k_dp_hw *dp_hw, u8 *addr,\ndrivers/net/wireless/ath/ath12k/dp_peer.h:171:\t\t\t struct ath12k_dp_peer_create_params *params);\ndrivers/net/wireless/ath/ath12k/dp_peer.h-172-void ath12k_dp_peer_delete(struct ath12k_dp_hw *dp_hw, u8 *addr,\n--\ndrivers/net/wireless/ath/ath12k/mac.c=7745=int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7761-\tint ret = -EINVAL;\ndrivers/net/wireless/ath/ath12k/mac.c:7762:\tstruct ath12k_dp_peer_create_params dp_params = {};\ndrivers/net/wireless/ath/ath12k/mac.c-7763-\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7801-\ndrivers/net/wireless/ath/ath12k/mac.c:7802:\t\tret = ath12k_dp_peer_create(\u0026ah-\u003edp_hw, sta-\u003eaddr, \u0026dp_params);\ndrivers/net/wireless/ath/ath12k/mac.c-7803-\t\tif (ret) {\n--\ndrivers/net/wireless/ath/ath12k/mac.c=10387=int ath12k_mac_vdev_create(struct ath12k *ar, struct ath12k_link_vif *arvif)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-10403-\tstruct ath12k_dp_link_vif *dp_link_vif = NULL;\ndrivers/net/wireless/ath/ath12k/mac.c:10404:\tstruct ath12k_dp_peer_create_params params = {};\ndrivers/net/wireless/ath/ath12k/mac.c-10405-\tbool dp_peer_created = false;\n--\ndrivers/net/wireless/ath/ath12k/mac.c-10497-\t\tif (arvif-\u003elink_id \u003c IEEE80211_MLD_MAX_NUM_LINKS) {\ndrivers/net/wireless/ath/ath12k/mac.c:10498:\t\t\tret = ath12k_dp_peer_create(\u0026ah-\u003edp_hw, arvif-\u003ebssid, \u0026params);\ndrivers/net/wireless/ath/ath12k/mac.c-10499-\t\t\tif (ret) {\n"
} |
| 27/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 22540 output: 45 thoughts: 188 Thoughts: Okay, let's break this down. **Understanding the Dynamically-Accessed Functions** So, these functions aren't directly exported, but they are clearly not statically defined either. They're being called from `ath12k_mac_op_sta_state` and `ath12k_mac_vdev_create`. My task is to determine which *mac80211* operations are affected by this. Essentially, I need to understand which parts of the MAC layer are interacting with these dynamic functions. Therefore, I have identified the following specific operations (or ones which call modified functions) that are likely relevant: * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` Hold on a second. It looks like `ath12k_mac_handle_beacon_miss` is also modified... but is that an actual mac80211 operation? I need to clarify that point. I'll need to check the exact function definition to make sure. I must also consider if the modification causes it to behave as an op. |
| 28/2 | 2026/07/28 08:47 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_handle_beacon_miss",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=1988=void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-1995-\ndrivers/net/wireless/ath/ath12k/mac.c:1996:void ath12k_mac_handle_beacon_miss(struct ath12k *ar,\ndrivers/net/wireless/ath/ath12k/mac.c-1997-\t\t\t\t struct ath12k_link_vif *arvif)\n--\ndrivers/net/wireless/ath/ath12k/mac.h=183=void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb);\ndrivers/net/wireless/ath/ath12k/mac.h:184:void ath12k_mac_handle_beacon_miss(struct ath12k *ar,\ndrivers/net/wireless/ath/ath12k/mac.h-185-\t\t\t\t struct ath12k_link_vif *arvif);\n--\ndrivers/net/wireless/ath/ath12k/wmi.c=7523=static void ath12k_peer_sta_kickout_event(struct ath12k_base *ab, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/wmi.c-7566-\t\tif (arvif-\u003eahvif-\u003evif-\u003etype == NL80211_IFTYPE_STATION) {\ndrivers/net/wireless/ath/ath12k/wmi.c:7567:\t\t\tath12k_mac_handle_beacon_miss(ar, arvif);\ndrivers/net/wireless/ath/ath12k/wmi.c-7568-\t\t\tbreak;\n--\ndrivers/net/wireless/ath/ath12k/wmi.c=7580=static void ath12k_roam_event(struct ath12k_base *ab, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/wmi.c-7615-\tcase WMI_ROAM_REASON_BEACON_MISS:\ndrivers/net/wireless/ath/ath12k/wmi.c:7616:\t\tath12k_mac_handle_beacon_miss(ar, arvif);\ndrivers/net/wireless/ath/ath12k/wmi.c-7617-\t\tbreak;\n"
} |
| 29/2 | 2026/07/28 08:47 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 23751 output: 43 thoughts: 92 Thoughts: Okay, here's my interpretation of this scenario, focusing on the potential implications from my perspective as an expert: **Investigating WMI Event Handling in Relation to Firmware Interaction** Right, so we're looking at a situation where something is triggered via WMI event handlers. These events, as I understand it, are being sourced from the firmware. The key question is how this event gets generated. The initial thought is that a fuzzer, specifically Syzkaller in this case, might be injecting these events. This could happen if Syzkaller is targeting either the PCI/MHI interface, or the mac80211 interface, and there is a subsequent trigger of the WMI event. Given the context, I want to be certain that I investigate how `ath12k_mac_handle_beacon_miss` is involved in this. This specific function seems relevant, based on the information provided. But then my mind immediately goes to another closely related function and I also need to understand what the role of `ath12k_mac_handle_beacon` is within this process. It seems very relevant to understanding the full picture, and the potential root cause of this triggering. |
| 30/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_handle_beacon",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=1891=static void ath12k_control_beaconing(struct ath12k_link_vif *arvif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-1942-\ndrivers/net/wireless/ath/ath12k/mac.c:1943:static void ath12k_mac_handle_beacon_iter(void *data, u8 *mac,\ndrivers/net/wireless/ath/ath12k/mac.c-1944-\t\t\t\t\t struct ieee80211_vif *vif)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-1987-\ndrivers/net/wireless/ath/ath12k/mac.c:1988:void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb)\ndrivers/net/wireless/ath/ath12k/mac.c-1989-{\n--\ndrivers/net/wireless/ath/ath12k/mac.c-1991-\t\t\t\t\t\t IEEE80211_IFACE_ITER_NORMAL,\ndrivers/net/wireless/ath/ath12k/mac.c:1992:\t\t\t\t\t\t ath12k_mac_handle_beacon_iter,\ndrivers/net/wireless/ath/ath12k/mac.c-1993-\t\t\t\t\t\t skb);\n--\ndrivers/net/wireless/ath/ath12k/mac.c-1995-\ndrivers/net/wireless/ath/ath12k/mac.c:1996:void ath12k_mac_handle_beacon_miss(struct ath12k *ar,\ndrivers/net/wireless/ath/ath12k/mac.c-1997-\t\t\t\t struct ath12k_link_vif *arvif)\n--\ndrivers/net/wireless/ath/ath12k/mac.h=182=int ath12k_mac_wait_tx_complete(struct ath12k *ar);\ndrivers/net/wireless/ath/ath12k/mac.h:183:void ath12k_mac_handle_beacon(struct ath12k *ar, struct sk_buff *skb);\ndrivers/net/wireless/ath/ath12k/mac.h:184:void ath12k_mac_handle_beacon_miss(struct ath12k *ar,\ndrivers/net/wireless/ath/ath12k/mac.h-185-\t\t\t\t struct ath12k_link_vif *arvif);\n--\ndrivers/net/wireless/ath/ath12k/wmi.c=7229=static void ath12k_mgmt_rx_event(struct ath12k_base *ab, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/wmi.c-7365-\tif (ieee80211_is_beacon(hdr-\u003eframe_control))\ndrivers/net/wireless/ath/ath12k/wmi.c:7366:\t\tath12k_mac_handle_beacon(ar, skb);\ndrivers/net/wireless/ath/ath12k/wmi.c-7367-\n--\ndrivers/net/wireless/ath/ath12k/wmi.c=7523=static void ath12k_peer_sta_kickout_event(struct ath12k_base *ab, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/wmi.c-7566-\t\tif (arvif-\u003eahvif-\u003evif-\u003etype == NL80211_IFTYPE_STATION) {\ndrivers/net/wireless/ath/ath12k/wmi.c:7567:\t\t\tath12k_mac_handle_beacon_miss(ar, arvif);\ndrivers/net/wireless/ath/ath12k/wmi.c-7568-\t\t\tbreak;\n--\ndrivers/net/wireless/ath/ath12k/wmi.c=7580=static void ath12k_roam_event(struct ath12k_base *ab, struct sk_buff *skb)\n--\ndrivers/net/wireless/ath/ath12k/wmi.c-7615-\tcase WMI_ROAM_REASON_BEACON_MISS:\ndrivers/net/wireless/ath/ath12k/wmi.c:7616:\t\tath12k_mac_handle_beacon_miss(ar, arvif);\ndrivers/net/wireless/ath/ath12k/wmi.c-7617-\t\tbreak;\n"
} |
| 31/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 25328 output: 46 thoughts: 223 Thoughts: **Analyzing Potential Fuzzing Targets in the ath12k Driver** Okay, so I've been looking at potential areas for fuzzing in this `ath12k` driver. It looks like some of these functions are called from a WMI event handler, which always makes me perk up because event handlers are often a good attack surface. Let me break down the interesting functions I've identified so far. The key focus symbols seem to be: `ath12k_mac_op_change_vif_links`, `ath12k_mac_op_hw_scan`, `ath12k_mac_op_set_key`, `ath12k_mac_op_sta_state`, `ath12k_mac_op_flush`, `ath12k_mac_op_reconfig_complete`, `ath12k_mac_handle_beacon_miss`, and `ath12k_mac_handle_beacon`. These definitely deserve a closer look for vulnerabilities. Wait a second, now *`ath12k_mac_dp_peer_cleanup`* is particularly interesting, given its call path - it’s called from `ath12k_mac_peer_cleanup_all`, which in turn comes from `ath12k_mac_unregister`. That chain indicates potential memory management issues, especially with the unregister operation. That's *definitely* worth fuzzing. The dependency context makes it a good candidate. And what about `ath12k_core_reconfigure_on_crash`? That could be another good target, too, depending on how the system reacts. I'll need to investigate that one a little more. |
| 32/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_core_reconfigure_on_crash",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/core.c=1311=int ath12k_core_qmi_firmware_ready(struct ath12k_base *ab)\n--\ndrivers/net/wireless/ath/ath12k/core.c-1384-\ndrivers/net/wireless/ath/ath12k/core.c:1385:static int ath12k_core_reconfigure_on_crash(struct ath12k_base *ab)\ndrivers/net/wireless/ath/ath12k/core.c-1386-{\n--\ndrivers/net/wireless/ath/ath12k/core.c=1634=static void ath12k_core_restart(struct work_struct *work)\n--\ndrivers/net/wireless/ath/ath12k/core.c-1640-\ndrivers/net/wireless/ath/ath12k/core.c:1641:\tret = ath12k_core_reconfigure_on_crash(ab);\ndrivers/net/wireless/ath/ath12k/core.c-1642-\tif (ret) {\n"
} |
| 33/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26260 output: 40 thoughts: 146 Thoughts: **Analyzing the ath12k Restart Process** Okay, so I'm looking at this function, and it seems... static. The core of this process appears to be `ath12k_core_restart`. Ah, wait a minute, `ath12k_core_restart` rings a bell... it's a workqueue function. Good, I'll definitely keep that in mind, and I'll add that piece of information to the mental model. Now, let's step back and consider the configurations involved. Clearly, `ATH12K` is central. But it relies on `MAC80211 && HAS_DMA && PCI`. Therefore, to build this module, I need to ensure `ATH12K`, `MAC80211`, and `PCI` are all defined. I have to make a note of this. Are there any other config options tied to this driver? I'll need to double-check the `drivers/net/wireless/ath/ath12k/Makefile` to confirm if there are any other config prerequisites. |
| 34/2 | 2026/07/28 08:48 | tool | read-file |
0mArgs:{
"File": "drivers/net/wireless/ath/ath12k/Makefile",
"FirstLine": 1,
"LineCount": 20
}Results: {
"Contents": " 1:\t# SPDX-License-Identifier: BSD-3-Clause-Clear\n 2:\tobj-$(CONFIG_ATH12K) += ath12k.o\n 3:\tath12k-y += core.o \\\n 4:\t\t hal.o \\\n 5:\t\t wmi.o \\\n 6:\t\t mac.o \\\n 7:\t\t reg.o \\\n 8:\t\t htc.o \\\n 9:\t\t qmi.o \\\n 10:\t\t dp.o \\\n 11:\t\t dp_tx.o \\\n 12:\t\t dp_rx.o \\\n 13:\t\t dp_htt.o \\\n 14:\t\t dp_peer.o \\\n 15:\t\t debug.o \\\n 16:\t\t ce.o \\\n 17:\t\t peer.o \\\n 18:\t\t dbring.o \\\n 19:\t\t mhi.o \\\n 20:\t\t pci.o \\\n"
} |
| 35/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 26943 output: 48 thoughts: 866 Thoughts: **Analysis of the ATH12K Patch for Fuzzing Suitability** Okay, let's break this down. First, the core config seems to be `ATH12K`. I'll definitely flag both `ATH12K` and `MAC80211` in the `EnableConfigs`. Just to be thorough, I should check for any related configs like `ATH12K_DEBUG` or `ATH12K_TRACING`, though the patch itself doesn't appear to depend on them directly. I'll keep an eye out for them, just in case. Now, for the key functions to focus on. I need to list the relevant `FocusSymbols`: * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` * `ath12k_mac_handle_beacon_miss` * `ath12k_mac_handle_beacon` * `ath12k_core_restart` * `ath12k_dp_peer_create` * `ath12k_dp_peer_delete` Wait, hold on. `ath12k_dp_peer_create` and `ath12k_dp_peer_delete` aren't *exported*, but they *aren't* static either. Interesting. They are good targets. Let me check if `ath12k_dp_peer_find_by_peerid` is exported. Yes, it's exported! And, looking at the patch, it seems to be exposed with `EXPORT_SYMBOL(ath12k_dp_peer_find_by_peerid);`. This suggests it's a deliberate API entrypoint, even though it's called from the data path (rx). I need to include that one. Okay, let me refine the `FocusSymbols` list, taking that into account: * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` * `ath12k_mac_handle_beacon_miss` * `ath12k_mac_handle_beacon` * `ath12k_core_restart` * `ath12k_dp_peer_find_by_peerid` Now, let's address the prompt's exclusion criteria. It says to return `WorthFuzzing=false` if the patch *only* contains code in specific vendor-specific drivers that require physical hardware. Specifically, drivers like "mlxsw, pds_core, qed, ionic, amdgpu". The critical question: Is `ath12k` considered one of *those* types of drivers? Technically, yes, an `ATH12K` driver requires a Qualcomm Wi-Fi 7 PCIe card, which is physical hardware. However, I know from experience that syzkaller *does* fuzz `ath12k` using the PCI fuzzer. This fuzzer emulates the PCI device by intercepting config space and MMIO accesses. It's designed specifically for drivers that depend on hardware not normally present. Moreover, the prompt lists specific examples, and Wi-Fi drivers aren't among them. Also, the commit message includes the phrase `syz-cluster: applied patch under review`, suggesting this is a patch generated by syzkaller. Therefore, because syzkaller *can* handle emulated hardware, this patch is probably related to an actual vulnerability discovered using fuzzing. Given this context, I'll confidently return `WorthFuzzing=true`. One last thing, let me double check that `ath12k_mac_op_change_vif_links` is an actual mac80211 operation. Always good to be certain. |
| 36/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_change_vif_links",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=4304=int\ndrivers/net/wireless/ath/ath12k/mac.c:4305:ath12k_mac_op_change_vif_links(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.c-4306-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-4357-}\ndrivers/net/wireless/ath/ath12k/mac.c:4358:EXPORT_SYMBOL(ath12k_mac_op_change_vif_links);\ndrivers/net/wireless/ath/ath12k/mac.c-4359-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=229=int\ndrivers/net/wireless/ath/ath12k/mac.h:230:ath12k_mac_op_change_vif_links\ndrivers/net/wireless/ath/ath12k/mac.h-231-\t\t\t(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1114-\t.vif_cfg_changed\t\t= ath12k_mac_op_vif_cfg_changed,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1115:\t.change_vif_links = ath12k_mac_op_change_vif_links,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1116-\t.configure_filter\t\t= ath12k_mac_op_configure_filter,\n"
} |
| 37/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 29361 output: 45 thoughts: 32 Thoughts: Okay, here's my interpretation of those thoughts, presented as a first-person summary, keeping in mind my expertise: **Checking the mac80211 Operation** Right, that's definitely a `mac80211` operation. Got it. Now, the next logical step is to dive right into the `ath12k_mac_op_hw_scan` function. That's where the core logic for the hardware scan likely resides, so let's get into it. |
| 38/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_hw_scan",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=5570=static int ath12k_mac_initiate_hw_scan(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-5733-\ndrivers/net/wireless/ath/ath12k/mac.c:5734:int ath12k_mac_op_hw_scan(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.c-5735-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-5816-}\ndrivers/net/wireless/ath/ath12k/mac.c:5817:EXPORT_SYMBOL(ath12k_mac_op_hw_scan);\ndrivers/net/wireless/ath/ath12k/mac.c-5818-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=235=void ath12k_mac_op_configure_filter(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/mac.h-238-\t\t\t\t u64 multicast);\ndrivers/net/wireless/ath/ath12k/mac.h:239:int ath12k_mac_op_hw_scan(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.h-240-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1116-\t.configure_filter\t\t= ath12k_mac_op_configure_filter,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1117:\t.hw_scan = ath12k_mac_op_hw_scan,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1118-\t.cancel_hw_scan = ath12k_mac_op_cancel_hw_scan,\n"
} |
| 39/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 30179 output: 45 thoughts: 32 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: **Diving into the MAC80211 Operation** Ah, right, this is a mac80211 operation, no question. Based on the context, I think we're likely dealing with a key setting function. Let's dig into the details and make sure we've got the correct implementation. My focus now is on confirming the right routine - `ath12k_mac_op_set_key`. I'll need to double check the specifics of this function, since that's where the work happens. |
| 40/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_set_key",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=6162=static int ath12k_mac_update_key_cache(struct ath12k_vif_cache *cache,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6200-\ndrivers/net/wireless/ath/ath12k/mac.c:6201:int ath12k_mac_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,\ndrivers/net/wireless/ath/ath12k/mac.c-6202-\t\t\t struct ieee80211_vif *vif, struct ieee80211_sta *sta,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-6289-}\ndrivers/net/wireless/ath/ath12k/mac.c:6290:EXPORT_SYMBOL(ath12k_mac_op_set_key);\ndrivers/net/wireless/ath/ath12k/mac.c-6291-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=242=void ath12k_mac_op_cancel_hw_scan(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.h-243-\t\t\t\t struct ieee80211_vif *vif);\ndrivers/net/wireless/ath/ath12k/mac.h:244:int ath12k_mac_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,\ndrivers/net/wireless/ath/ath12k/mac.h-245-\t\t\t struct ieee80211_vif *vif, struct ieee80211_sta *sta,\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1118-\t.cancel_hw_scan = ath12k_mac_op_cancel_hw_scan,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1119:\t.set_key = ath12k_mac_op_set_key,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1120-\t.set_rekey_data\t = ath12k_mac_op_set_rekey_data,\n"
} |
| 41/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 31082 output: 45 thoughts: 32 Thoughts: Okay, here's my interpretation of those thoughts, presented as a first-person summary, keeping in mind my expertise: **Checking the mac80211 STA State Operation** Alright, that's definitely a mac80211 operation. Specifically, it's pretty clear we're dealing with the `ath12k_mac_op_sta_state`. Now, I need to focus on what this function is actually doing. I'll need to remember the intricacies of how ath12k handles station state within the mac80211 framework. Time to mentally review the control flow. What are the key data structures and locking that this op uses. Is the right information being passed to the function, and is it returning what it should be? I will need to delve into the code to ensure its stability. |
| 42/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_sta_state",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=7649=static int ath12k_mac_select_links(struct ath12k_base *ab,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7744-\ndrivers/net/wireless/ath/ath12k/mac.c:7745:int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.c-7746-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/mac.c-7942-}\ndrivers/net/wireless/ath/ath12k/mac.c:7943:EXPORT_SYMBOL(ath12k_mac_op_sta_state);\ndrivers/net/wireless/ath/ath12k/mac.c-7944-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=247=void ath12k_mac_op_set_rekey_data(struct ieee80211_hw *hw,\n--\ndrivers/net/wireless/ath/ath12k/mac.h-249-\t\t\t\t struct cfg80211_gtk_rekey_data *data);\ndrivers/net/wireless/ath/ath12k/mac.h:250:int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.h-251-\t\t\t struct ieee80211_vif *vif,\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1120-\t.set_rekey_data\t = ath12k_mac_op_set_rekey_data,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1121:\t.sta_state = ath12k_mac_op_sta_state,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1122-\t.sta_set_txpwr\t\t\t= ath12k_mac_op_sta_set_txpwr,\n"
} |
| 43/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 31988 output: 43 thoughts: 30 Thoughts: Okay, here's my summarized thought process, presented as if I were thinking it: **Analyzing a mac80211 Operation** Alright, yep, that looks like we're dealing with a mac80211 operation here. Good. Now, the next step is to examine the `ath12k_mac_op_flush` function specifically. That's where the critical logic for this part of the process resides. Let's dig in and see what's happening within that function to understand the full picture. |
| 44/2 | 2026/07/28 08:48 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_flush",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=12676=int ath12k_mac_wait_tx_complete(struct ath12k *ar)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-12683-\ndrivers/net/wireless/ath/ath12k/mac.c:12684:void ath12k_mac_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,\ndrivers/net/wireless/ath/ath12k/mac.c-12685-\t\t\t u32 queues, bool drop)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-12719-}\ndrivers/net/wireless/ath/ath12k/mac.c:12720:EXPORT_SYMBOL(ath12k_mac_op_flush);\ndrivers/net/wireless/ath/ath12k/mac.c-12721-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=306=int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,\ndrivers/net/wireless/ath/ath12k/mac.h-307-\t\t\t struct survey_info *survey);\ndrivers/net/wireless/ath/ath12k/mac.h:308:void ath12k_mac_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,\ndrivers/net/wireless/ath/ath12k/mac.h-309-\t\t\t u32 queues, bool drop);\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1139-\t.get_survey\t\t\t= ath12k_mac_op_get_survey,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1140:\t.flush\t\t\t\t= ath12k_mac_op_flush,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1141-\t.sta_statistics\t\t\t= ath12k_mac_op_sta_statistics,\n"
} |
| 45/2 | 2026/07/28 08:48 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 32811 output: 46 thoughts: 33 Thoughts: Okay, here's my take on those thoughts, framed as an expert's internal monologue: **Quick Scan: mac80211 Operation Confirmation & Function Check** Alright, that's definitely a mac80211 operation, no question. Now, let's drill down. I need to understand what's happening at this specific point. The next logical step is to examine the `ath12k_mac_op_reconfig_complete` function. That's where the actual completion and follow-up actions of the reconfiguration process are managed. Time to see what's going on within. |
| 46/2 | 2026/07/28 08:49 | tool | grepper |
0mArgs:{
"Expression": "ath12k_mac_op_reconfig_complete",
"PathPrefix": "drivers/net/wireless/ath/ath12k/"
}Results: {
"Output": "drivers/net/wireless/ath/ath12k/mac.c=13524=void\ndrivers/net/wireless/ath/ath12k/mac.c:13525:ath12k_mac_op_reconfig_complete(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.c-13526-\t\t\t\tenum ieee80211_reconfig_type reconfig_type)\n--\ndrivers/net/wireless/ath/ath12k/mac.c-13606-}\ndrivers/net/wireless/ath/ath12k/mac.c:13607:EXPORT_SYMBOL(ath12k_mac_op_reconfig_complete);\ndrivers/net/wireless/ath/ath12k/mac.c-13608-\n--\ndrivers/net/wireless/ath/ath12k/mac.h=212=void\ndrivers/net/wireless/ath/ath12k/mac.h:213:ath12k_mac_op_reconfig_complete(struct ieee80211_hw *hw,\ndrivers/net/wireless/ath/ath12k/mac.h-214-\t\t\t\tenum ieee80211_reconfig_type reconfig_type);\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c=1103=static const struct ieee80211_ops ath12k_ops_wifi7 = {\n--\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1107-\t.stop = ath12k_mac_op_stop,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c:1108:\t.reconfig_complete = ath12k_mac_op_reconfig_complete,\ndrivers/net/wireless/ath/ath12k/wifi7/hw.c-1109-\t.add_interface = ath12k_mac_op_add_interface,\n"
} |
| 47/2 | 2026/07/28 08:49 | llm | patch-evaluator |
0mModel:gemini-3.1-pro-preview Args: null Results: null Tokens: input: 33549 output: 270 thoughts: 760 Thoughts: **My Fuzzing Strategy: A Refined List of Targets** Okay, so I've confirmed that these are all `mac80211` operations. That's fantastic! It means these functions, `ath12k_*`, are standard entry points and should be reachable through standard `nl80211` fuzzing. I'm seeing a clear path to exploitability here. Initially, I had a list of targets: * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` * `ath12k_mac_handle_beacon_miss` * `ath12k_mac_handle_beacon` * `ath12k_core_restart` * `ath12k_dp_peer_find_by_peerid` But I need to be strategic. `ath12k_dp_peer_find_by_peerid` is called from the data path (`ath12k_dp_rx_process_mon_status` and `ath12k_dp_rx_process_mon_rings`), which is probably going to be too "hot" for initial fuzzing. So, I'll remove it. Similarly, `ath12k_mac_handle_beacon` gets called for *every* beacon, so that's also too hot. `ath12k_mac_handle_beacon_miss` is a better candidate; less frequent, but still relevant. I will keep it for now. And of course, `ath12k_core_restart` looks promising as it's triggered by a crash. My refined list of FocusSymbols is now: * `ath12k_mac_op_change_vif_links` * `ath12k_mac_op_hw_scan` * `ath12k_mac_op_set_key` * `ath12k_mac_op_sta_state` * `ath12k_mac_op_flush` * `ath12k_mac_op_reconfig_complete` * `ath12k_mac_handle_beacon_miss` * `ath12k_core_restart` This should give me a solid set of control-path functions to work with, that are either directly modified or call modified functions. Now, let's verify the necessary configurations. It's `ATH12K` and `MAC80211`, obviously. But `ATH12K` depends on `MAC80211`, `HAS_DMA`, and `PCI`. `HAS_DMA` is probably enabled anyway, but I should definitely include `PCI`. So, the EnableConfigs are: `ATH12K`, `MAC80211`, and `PCI`. I've checked for other relevant configs, like `ATH12K_AHB` and `ATH12K_DEBUG`, but nothing else seems specifically relevant to this patch. I'm feeling good about this now. I'm ready to call `set-results`. |
| 48/2 | 2026/07/28 08:49 | tool | set-results |
0mArgs:{
"EnableConfigs": [
"ATH12K",
"MAC80211",
"PCI"
],
"FocusSymbols": [
"ath12k_mac_op_change_vif_links",
"ath12k_mac_op_hw_scan",
"ath12k_mac_op_set_key",
"ath12k_mac_op_sta_state",
"ath12k_mac_op_flush",
"ath12k_mac_op_reconfig_complete",
"ath12k_mac_handle_beacon_miss",
"ath12k_core_restart"
],
"Reasoning": "The patch modifies the ath12k Wi-Fi driver to handle crash recovery and MLO peer ID assignment. Although ath12k is a hardware-specific driver, syzkaller is able to fuzz it using the PCI fuzzer to emulate the device and register it with mac80211, allowing standard nl80211 fuzzing to reach the modified mac80211 ops. The patch contains functional changes to control-path operations that should be fuzzed.",
"WorthFuzzing": true
}Results: {
"EnableConfigs": [
"ATH12K",
"MAC80211",
"PCI"
],
"FocusSymbols": [
"ath12k_mac_op_change_vif_links",
"ath12k_mac_op_hw_scan",
"ath12k_mac_op_set_key",
"ath12k_mac_op_sta_state",
"ath12k_mac_op_flush",
"ath12k_mac_op_reconfig_complete",
"ath12k_mac_handle_beacon_miss",
"ath12k_core_restart"
],
"Reasoning": "The patch modifies the ath12k Wi-Fi driver to handle crash recovery and MLO peer ID assignment. Although ath12k is a hardware-specific driver, syzkaller is able to fuzz it using the PCI fuzzer to emulate the device and register it with mac80211, allowing standard nl80211 fuzzing to reach the modified mac80211 ops. The patch contains functional changes to control-path operations that should be fuzzed.",
"WorthFuzzing": true
} |
| Total Calls | Total Tokens | Avg Tokens | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|
| Total Calls | Total Duration (Seconds) | Avg Duration (Seconds) |
|---|