Re: [PATCH] wifi: ath12k: fix wrong register read for RU start index of 80_3 segment

From: Jeff Johnson

Date: Fri Oct 30 2026 - 20:51:17 EST


On 10/30/2026 2:09 AM, Jose Ignacio Tornos Martinez wrote:
> The RU start index for the fourth 80 MHz segment (80_3) is read from
> rx_usr_info->info2 instead of rx_usr_info->info3. The bitmask used
> (HAL_RX_USR_INFO3_RU_START_IDX_80_3) is correct for info3, so applying
> it to info2 extracts garbage bits, producing an out-of-range shift
> exponent that triggers a UBSAN splat:
>
> UBSAN: shift-out-of-bounds in drivers/net/wireless/ath/ath12k/wifi7/dp_mon.c:302:22
> shift exponent 284 is too large for 64-bit type 'long long unsigned int'
> Call Trace:
> ath12k_wifi7_dp_mon_hal_rx_parse_user_info.cold+0x3a/0xef7 [ath12k_wifi7]
> ath12k_wifi7_dp_mon_rx_parse_status_tlv+0x621/0x990 [ath12k_wifi7]
> ath12k_wifi7_dp_mon_parse_rx_dest+0xa9/0x2b0 [ath12k_wifi7]
> ath12k_wifi7_dp_mon_srng_process+0x34f/0x560 [ath12k_wifi7]
> ath12k_wifi7_dp_mon_process_ring+0x205/0x270 [ath12k_wifi7]
> ath12k_wifi7_dp_service_srng+0x1b4/0x5e0 [ath12k_wifi7]
> ath12k_pci_ext_grp_napi_poll+0x43/0x100 [ath12k]
>
> Read from the suitable info (in this case info3) like the other three
> segments do.
>
> Fixes: 5db19c488413 ("wifi: ath12k: Move MU user processing to Wi-Fi 7 module")

This is not the correct fixes tag since the issue predates relocating the
code. I had my review agent follow the guidance proposed in [1] and it came
up with:

Fixes: e6fa62bada87 ("wifi: ath12k: Add HAL_RX_PPDU_START_USER_INFO TLV parsing support")

No need to repost since my automation will pick up both tags now.

/jeff

[1] https://lore.kernel.org/all/20261020142534.3533478-1-sashal@xxxxxxxxxx/
docs: submitting-patches: say which commit a Fixes tag names