In 2021, a subtle yet critical vulnerability was found in the Linux kernel's mt76 driver, specifically affecting the MediaTek mt7915 WiFi chipset. This issue, tracked as CVE-2021-47028, caused the kernel to improperly report transmission rates due to *unsafe handling of rate_info pointers*. While not a remote code execution hole, this bug led to misleading WiFi statistics — which could disrupt mesh network metrics, user experience, and triggered dangerous kernel tracebacks.

Let's break down what happened, the technical details, how it appeared, and how it was fixed. If you are a user, developer, or maintainer working with the mt76 driver family (e.g., on OpenWrt or any embedded Linux device), this analysis will help you understand why the patch matters and how to avoid similar mistakes.

What is CVE-2021-47028?

The CVE relates to a bug in txrate reporting inside the mt76 driver for the mt7915 chipset. It’s all about how the code interprets transmission rates for packets sent or received over WiFi — important for tools that monitor throughput, automate mesh route selection, or perform network tuning.

Root Cause

The problem was in the function that reported the bitrate — it failed to *properly check* if the rate_info structure was valid before accessing its fields. This led to possible null pointer dereferences or garbage-in/garbage-out situations.

Here’s a relevant kernel log trace:

[ 1215.161863] Call trace:
[ 1215.164307]  cfg80211_calculate_bitrate+x124/x200 [cfg80211]
[ 1215.170139]  ieee80211s_update_metric+x80/xc [mac80211]
[ 1215.175624]  ieee80211_tx_status_ext+x508/x838 [mac80211]
[ 1215.181190]  mt7915_mcu_get_rx_rate+x28c/x8d [mt7915e]
[ 1215.186580]  mt7915_mac_tx_free+x324/x7c [mt7915e]
[ 1215.191623]  mt7915_queue_rx_skb+xa8/xd [mt7915e]
[ 1215.196582]  mt76_dma_cleanup+x7b/x11d [mt76]
[ 1215.201276]  __napi_poll+x38/xf8
[ 1215.204668]  napi_workfn+x40/x80
[ 1215.208062]  process_one_work+x1fc/x390
[ 1215.212062]  worker_thread+x48/x4d
[ 1215.215715]  kthread+x120/x128
[ 1215.218935]  ret_from_fork+x10/x1c

The chain shows how the bug bubbles up from the mt7915 driver to the higher-level cfg80211 (configuration and monitoring for wireless drivers), ultimately resulting in invalid bitrate values presented to users and admins.

Anatomy of the Vulnerable Code

The bug existed because the code assumed the presence and validity of the rate_info block. Here’s a simplified snippet (before the fix):

// Imagine this is part of mt7915_mac_tx_free or a related callback
struct rate_info *ri = get_rate_info(...);  // may return NULL or invalid

// ...later...
bitrate = cfg80211_calculate_bitrate(ri); // DANGEROUS if ri is not checked!

If get_rate_info returned NULL or an unchecked/uninitialized struct, cfg80211_calculate_bitrate() would access bogus fields, leading to wrong info or kernel panics.

The Patch

The fix is as simple as it is important: don't trust what you haven't checked. Before using rate_info, make sure it's safe.

Patched code (simplified)

struct rate_info *ri = get_rate_info(...);
u32 bitrate = ;

if (ri) { // new check!
    bitrate = cfg80211_calculate_bitrate(ri);
} else {
    // fallback or default value to avoid bogus reporting
    bitrate = ;
}

See the official patch here:
- Kernel.org commit: "mt76: mt7915: fix txrate reporting" (commit d760a7aa)
- Linux Wireless ML discussion

Is This a Security Hole?

- No remote code execution, but it causes broken reporting — userland tools might make bad decisions based on invalid data.
- Potential Denial-of-Service (DoS): Bad values could crash services, automated scripts, or mesh daemons adjusting their paths based on bogus throughput.
- Attack scenario: A maliciously crafted packet, or unintended driver state, could trigger this path. An attacker in-range might exploit this for disruption.

How to Check If You’re Vulnerable

Run dmesg or journalctl and look for traces referencing
mt7915_mcu_get_rx_rate
or
cfg80211_calculate_bitrate
with null pointer or oops conditions.

Never trust kernel pointers or structs passed between layers.

- Always check for null or invalid state before dereferencing, especially in fast paths like network drivers.
- “Silent failures” (like the wrong number reported by WiFi tools) can sometimes cause just as many real-world problems as big system crashes.

References

- Kernel Patch — mt76: mt7915: fix txrate reporting (git.kernel.org)
- CVE-2021-47028 on CVE Details
- Linux Wireless Mailing List Discussion
- mt76 Driver on GitHub

Conclusion

CVE-2021-47028 may seem like a technical footnote in the history of Linux wireless drivers, but it serves as a classic example of why you should always double-check what you use inside the kernel code, especially for hardware abstraction layers. Staying up to date with kernel patches is essential for both security and functionality.

*If you manage Linux-based networking hardware, apply the fix, and rest easy knowing your bitrate numbers are trustworthy again.*

Timeline

Published on: 02/28/2024 09:15:39 UTC
Last modified on: 12/06/2024 20:53:43 UTC