https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 09 Oct 2026 15:49:19 +0000 https://cve.radiocsirt.org/vuln/cve-2021-47349 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mwifiex: bring down link before deleting interface</p> <p>We can deadlock when rmmod&#39;ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock.</p> <p>nl80211_del_interface() already handles a very similar case, with a nice description:</p> <p>/* * We hold RTNL, so this is safe, without RTNL opencount cannot * reach 0, and thus the rdev cannot be deleted. * * We need to do it for the dev_close(), since that will call * the netdev notifiers, and we need to acquire the mutex there * but don&#39;t know if we get there from here or from some other * place (e.g. &#34;ip link set ... down&#34;). */ mutex_unlock(&amp;rdev-&gt;wiphy.mtx); ...</p> <p>Do similarly for mwifiex teardown, by ensuring we bring the link down first.</p> <p>Sample deadlock trace:</p> <p>[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lo…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mwifiex: bring down link before deleting interface</p> <p>We can deadlock when rmmod&#39;ing the driver or going through firmware reset, because the cfg80211_unregister_wdev() has to bring down the link for us, ... which then grab the same wiphy lock.</p> <p>nl80211_del_interface() already handles a very similar case, with a nice description:</p> <p>/* * We hold RTNL, so this is safe, without RTNL opencount cannot * reach 0, and thus the rdev cannot be deleted. * * We need to do it for the dev_close(), since that will call * the netdev notifiers, and we need to acquire the mutex there * but don&#39;t know if we get there from here or from some other * place (e.g. &#34;ip link set ... down&#34;). */ mutex_unlock(&amp;rdev-&gt;wiphy.mtx); ...</p> <p>Do similarly for mwifiex teardown, by ensuring we bring the link down first.</p> <p>Sample deadlock trace:</p> <p>[ 247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds. [ 247.110630] Not tainted 5.12.4 #5 [ 247.115796] &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message. [ 247.124557] task:rmmod state:D stack: 0 pid: 2119 ppid: 2114 flags:0x00400208 [ 247.133905] Call trace: [ 247.136644] __switch_to+0x130/0x170 [ 247.140643] __schedule+0x714/0xa0c [ 247.144548] schedule_preempt_disabled+0x88/0xf4 [ 247.149714] __mutex_lock_common+0x43c/0x750 [ 247.154496] mutex_lo…</p> https://cve.radiocsirt.org/vuln/cve-2021-47349