CVE-2021-47225

What it actually does

Deadlock occurs in mac80211 when AP_VLAN interfaces remain up while the parent AP interface is closed, because dev_close() is invoked while holding the wiphy mutex, which then re-enters cfg80211 netdev notifier and attempts to reacquire the same mutex.

Why it matters to the business

Wireless access-point functionality on Linux systems can become unresponsive, requiring a reboot to restore service and potentially disrupting connected users or dependent network operations.

How an attack unfolds

An attacker with local access creates AP_VLAN interfaces attached to an active AP interface, then closes the parent AP interface; the resulting mutex deadlock halts the wireless stack.

How to fix it

Update the Linux kernel to a version containing the fix that prevents iftype changes while AP_VLANs are present and moves the dev_close() loop outside the wiphy mutex section; apply the stable patch series released after 2021-07-19.

How to confirm the fix worked

Confirm the running kernel contains commit 8d3a3e6c7f3a or later equivalent backport; attempt to reproduce the original AP_VLAN close sequence in a test environment and verify no deadlock occurs.

Typical attack path

1. Obtain local access to a Linux system using the mac80211 wireless stack.
2. Create one or more AP_VLAN interfaces bound to an active AP interface.
3. Issue a close or iftype change operation on the parent AP interface.
4. Trigger the deadlock that leaves the wiphy mutex permanently held.

How to detect it

Review dmesg and kernel logs for repeated mutex deadlock warnings or hung task messages involving cfg80211 or mac80211 during AP interface teardown; inspect audit logs for wireless interface creation and deletion events.

What your security team should do

• Prioritize kernel upgrades on all systems exposing wireless AP functionality.
• Restrict local user ability to create or manage AP_VLAN interfaces via policy or capabilities.
• Monitor for wireless interface creation events in system logs.