On 1 April 2016 at 17:56, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > I saw this splat yesterday evening... Any ideas on what this could be? > > I'll add some bounds checking on the rate->idx in case that is the issue... > > > (gdb) l *(sta_set_rate_info_tx+0x1b3) > 0x38dcc is in sta_set_rate_info_tx > (/home/greearb/git/linux-4.4.dev.y/net/mac80211/cfg.c:457). > 452 u16 brate; > 453 > 454 sband = sta->local->hw.wiphy->bands[ > 455 > ieee80211_get_sdata_band(sta->sdata)]; > 456 brate = sband->bitrates[rate->idx].bitrate; > 457 rinfo->legacy = DIV_ROUND_UP(brate, 1 << shift); > 458 } > 459 if (rate->flags & IEEE80211_TX_RC_40_MHZ_WIDTH) > 460 rinfo->bw = RATE_INFO_BW_40; > 461 else if (rate->flags & IEEE80211_TX_RC_80_MHZ_WIDTH) > (gdb) > > > ================================================================== > BUG: KASAN: global-out-of-bounds in sta_set_rate_info_tx+0x1b3/0x262 > [mac80211] at addr ffffffffa18a3c0c > Read of size 2 by task cat/19440 > Address belongs to variable ath10k_rates+0xac/0xfffffffffffd04c7 > [ath10k_core] This is interesting. The `rate` comes from sta's last_rate which is updated in tx_status(). Hmm.. From a quick look I suspect ath10k_wmi_mgmt_tx() reports the offending last_rate. The `info` isn't zero-ed but it may have some garbage from ath10k's internal txpath processing. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
