In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921e: fix crash in chip reset fail
In case of drv own fail in reset, we may need to run mac_reset several times. The sequence would trigger system crash as the log below.
Because we do not re-enable/schedule "txnapi" before disable it again, the process would keep waiting for state change in napidiable(). To avoid the problem and keep status synchronize for each run, goto final resource handling if drv own failed.
[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed [ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own [ 5859.633430] mt7921e 0000:3b:00.0: driver own failed [ 5859.633444] ------------[ cut here ]------------ [ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthreadpark+0x11d [ 5859.633717] Workqueue: mt76 mt7921macresetwork [mt7921common] [ 5859.633728] RIP: 0010:kthreadpark+0x11d/0x150 [ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202 ...... [ 5859.633766] Call Trace: [ 5859.633768] <TASK> [ 5859.633771] mt7921emacreset+0x176/0x6f0 [mt7921e] [ 5859.633778] mt7921macresetwork+0x184/0x3a0 [mt7921common] [ 5859.633785] ? mt7921macsettiming+0x520/0x520 [mt7921common] [ 5859.633794] ? _kasancheckread+0x11/0x20 [ 5859.633802] processonework+0x7ee/0x1320 [ 5859.633810] workerthread+0x53c/0x1240 [ 5859.633818] kthread+0x2b8/0x370 [ 5859.633824] ? processonework+0x1320/0x1320 [ 5859.633828] ? kthreadcompleteandexit+0x30/0x30 [ 5859.633834] retfrom_fork+0x1f/0x30 [ 5859.633842] </TASK>