The Linux kernel is the backbone of many operating systems, especially those running on servers, routers, IoT devices, and embedded platforms. Network drivers need to be efficient, stable, and bug-free because they handle critical data flows. In early 2021, a vulnerability was found—and later fixed—in the mt76 WiFi driver, specifically in its mt7915 component. Tracked as CVE-2021-47021, this bug caused memory leaks whenever a device was unregistered, potentially leading to system instability over time.
Let's break down this vulnerability, explain why it happened, look at relevant code snippets, and see how it was fixed.
Location: mt76 WiFi driver (mt7915_unregister_device in the mt7915 submodule)
- Affected Kernel Versions: Various before fix was applied—exact version depends on vendor/distribution
- Impact: System resources (memory) not freed correctly, causing leaks, possible system slowdown, or even failure if exploited over time
The Bug Explained
The mt76 kernel driver supports various MediaTek WiFi chips. When a device is unregistered (say, when the module is unloaded or the device is unplugged), it should clean up all allocated resources. This includes freeing any memory tied up with pending transmissions ("tx tokens" and TX work items).
The function mt7915_unregister_device() was supposed to clean these things up. However, before the fix, this function called mt76_free_pending_txwi() before calling mt7915_tx_token_put(). That’s the wrong order! The result: memory used for TX tokens never got released—a classic memory leak.
The Fix: Order of Function Calls
The correct order is to release (put) all tx tokens first, and only then free pending transmit work items. Otherwise, you'll still have dangling pointers, or unfreed memory blocks.
Before the fix (BAD)
// File: drivers/net/wireless/mediatek/mt76/mt7915/main.c
void mt7915_unregister_device(struct mt7915_phy *phy)
{
// ... previous code ...
mt76_free_pending_txwi(&dev->mt76);
mt7915_tx_token_put(dev);
// ... more cleanup ...
}
Here, freeing TX work items before releasing the tokens causes the leak.
After the fix (GOOD)
// Fixed order
void mt7915_unregister_device(struct mt7915_phy *phy)
{
// ... previous code ...
mt7915_tx_token_put(dev);
mt76_free_pending_txwi(&dev->mt76);
// ... more cleanup ...
}
Now, tokens are put before freeing the work items, so everything gets released as intended.
Exploit Details
This isn't a "remote code execution" or "privilege escalation" vulnerability. But it is still serious, especially on devices that run for a long time without a reboot:
- Attackers could potentially trigger device unregister/register cycles, on purpose, to force memory leaks—eventually leading to Denial of Service (DoS) as the kernel runs out of usable RAM
- Unprivileged users cannot directly trigger this unless they can manipulate device drivers (for example, by reloading modules or unplugging/replugging USB adapters)
- On routers or access points, this is a reliability issue, leading to service degradation over days or weeks
References
- CVE page: https://nvd.nist.gov/vuln/detail/CVE-2021-47021
Upstream kernel commit (fix):
Discussion thread:
https://lore.kernel.org/linux-wireless/20210614155658.26854-1-yongjun_wei@trend.com.cn/
Make sure your system is updated to a kernel with the patch for CVE-2021-47021.
- For embedded/IoT vendors: Update your forks and custom builds.
- For end users: Standard desktop/server Linux distros have likely patched this if you're running updates.
How to check (simple test)
- If the device can be hot unplugged, plug/unplug a few times while watching dmesg for memory leaks or increasing usage (with free -m).
Conclusion
CVE-2021-47021 is a good reminder: resource management bugs—though often "invisible"—can quietly cripple the reliability of any system, especially those that aren't regularly rebooted. The fix for this one was simple: just change the order of two cleanup calls. In kernel code, every little detail matters!
For network operators, home gateway users, or sysadmins—if you're reliant on MediaTek WiFi chips under Linux, make sure you're running with patched drivers. Even non-exploit memory leaks can lead to unexpected downtime.
Timeline
Published on: 02/28/2024 09:15:39 UTC
Last modified on: 12/09/2024 17:59:41 UTC