Search Linux Wireless

Re: [PATCH] wifi: mac80211: don't use rate mask for scanning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 29. Mar 12:47, Dmitry Antipov wrote:
> On 3/27/24 00:08, Johannes Berg wrote:
> 
> > From: Johannes Berg <johannes.berg@xxxxxxxxx>
> > 
> > The rate mask is intended for use during operation, and
> > can be set to only have masks for the currently active
> > band. As such, it cannot be used for scanning which can
> > be on other bands as well.
> > 
> > Simply ignore the rate masks during scanning to avoid
> > warnings from incorrect settings.
> > 
> > Reported-by: syzbot+fdc5123366fb9c3fdc6d@xxxxxxxxxxxxxxxxxxxxxxxxx
> > Closes: https://syzkaller.appspot.com/bug?extid=fdc5123366fb9c3fdc6d
> > Co-developed-by: Dmitry Antipov <dmantipov@xxxxxxxxx>
> > Signed-off-by: Dmitry Antipov <dmantipov@xxxxxxxxx>
> > Signed-off-by: Johannes Berg <johannes.berg@xxxxxxxxx>
> 
> Ugh. Fedor has reported (and I have confirmed) that this still may be
> reproduced with https://syzkaller.appspot.com/text?tag=ReproC&x=12a8fd7f680000
> as:
> 
> [   40.293787][ T5149] no supported rates for sta 08:02:11:00:00:01 (0xf, band 0) in rate_mask 0xfff with flags 0x10
> [   40.294789][ T5149] WARNING: CPU: 1 PID: 5149 at net/mac80211/rate.c:380 __rate_control_send_low+0x6af/0x810
> [   40.295624][ T5149] Modules linked in:
> [   40.296369][ T5149] CPU: 1 PID: 5149 Comm: repro3 Not tainted 6.9.0-rc1-00179-g46ad21a6b2e3 #1
> [   40.296918][ T5149] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
> [   40.297534][ T5149] RIP: 0010:__rate_control_send_low+0x6af/0x810
> [   40.297946][ T5149] Code: 8b ac a8 d4 00 00 00 e8 df 4d 4f f7 44 8b 44 24
> 04 45 89 f9 89 d9 48 8b 74 24 18 89 ea 48 c7 c7 60 68 4e 8c e8 62 a0 11 f7
> 90 <0f> 0b 90 90 e9 1f fd ff ff 48 8b 7c 24 28 e8 ce 16 ab f7 e9 13 fc
> [   40.299218][ T5149] RSP: 0018:ffffc9000350ed40 EFLAGS: 00010282
> [   40.299624][ T5149] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8150f9b9
> [   40.300192][ T5149] RDX: ffff88810b509cc0 RSI: ffffffff8150f9c6 RDI: 0000000000000001
> [   40.300743][ T5149] RBP: 000000000000000f R08: 0000000000000001 R09: 0000000000000000
> [   40.301291][ T5149] R10: 0000000000000000 R11: 0000000000000006 R12: ffff88801985f228
> [   40.301812][ T5149] R13: ffff888107edb088 R14: 000000000000000c R15: 0000000000000010
> [   40.302335][ T5149] FS:  00007f16474fe740(0000) GS:ffff888135c00000(0000) knlGS:0000000000000000
> [   40.302945][ T5149] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   40.303385][ T5149] CR2: 00007f16474ff0e8 CR3: 0000000109dc0000 CR4: 00000000000006f0
> [   40.303957][ T5149] Call Trace:
> [   40.304221][ T5149]  <TASK>
> [   40.308220][ T5149]  rate_control_send_low+0x116/0x7e0
> [   40.308786][ T5149]  rate_control_get_rate+0x1be/0x590
> [   40.309153][ T5149]  ieee80211_tx_h_rate_ctrl+0xaa1/0x1a50
> [   40.310581][ T5149]  invoke_tx_handlers_late+0x133b/0x2ae0
> [   40.312476][ T5149]  ieee80211_tx+0x306/0x420
> [   40.314290][ T5149]  ieee80211_xmit+0x30e/0x3e0
> [   40.314651][ T5149]  __ieee80211_tx_skb_tid_band+0x29b/0x700
> [   40.315090][ T5149]  ieee80211_tx_skb_tid+0x176/0x4f0
> [   40.315483][ T5149]  ieee80211_mgmt_tx+0x129a/0x2160
> [   40.315868][ T5149]  cfg80211_mlme_mgmt_tx+0x910/0x1570
> [   40.316277][ T5149]  nl80211_tx_mgmt+0x7ad/0xcf0
> [   40.317822][ T5149]  genl_family_rcv_msg_doit+0x205/0x2f0
> [   40.319083][ T5149]  genl_rcv_msg+0x56c/0x810
> [   40.321628][ T5149]  netlink_rcv_skb+0x16e/0x440
> [   40.324076][ T5149]  genl_rcv+0x28/0x40
> [   40.324359][ T5149]  netlink_unicast+0x545/0x820
> [   40.325810][ T5149]  netlink_sendmsg+0x8b8/0xd70
> [   40.327175][ T5149]  ____sys_sendmsg+0xacf/0xca0
> [   40.328673][ T5149]  ___sys_sendmsg+0x135/0x1e0
> [   40.330261][ T5149]  __sys_sendmsg+0x117/0x1f0
> [   40.330761][ T5149]  do_syscall_64+0xd3/0x260
> [   40.331047][ T5149]  entry_SYSCALL_64_after_hwframe+0x6d/0x75
> 
> Note that the backtrace is different and this
> one comes from MLME rather than scanning.
> 
> Dmitry
> 

Yeah, I think it might be caused by a completely different scenario not
related to scanning - which can be seen from the backtrace. So it may need
a different analysis and probably a fix in another place.

The warnings while scanning have been fixed with the proposed patch, I can
confirm, too.

--
Fedor




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux