[PATCH v3 0/1] wifi: mac80211: validate TX status rate metadata
From: Yuqi Xu <hidden>
Date: 2026-09-19 08:46:55
Hi Linux kernel maintainers, minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status into a group and rate index and uses those to index the minstrel_ht rate tables. Neither the common mac80211 status path nor the minstrel validators checked that the reported MCS, NSS and bandwidth are representable, so a malformed status report could walk past the end of struct minstrel_rate_stats. This is v3, reworked along the review comments on v2. Changes in v3: - Move the generic rate metadata validation into the common mac80211 TX status path (net/mac80211/status.c): the legacy ieee80211_tx_rate array and the rate_info based entries are sanitized before any status consumer runs. This follows the review feedback that values such as nss == 0 are generally invalid and should not be checked by minstrel only. - Keep only the checks that depend on minstrel_ht's own tables in rc80211_minstrel_ht.c: the supported number of spatial streams, the MCS group size and the supported bandwidths. - Drop Cc: stable and the severity wording. We could not identify an in-tree driver or firmware that reports such values; the reproducer uses the mac80211_hwsim userspace medium, which can only forge TX status for the radio it serves. This is driver metadata hardening, not a report we can attribute to real hardware. - Restore the Assisted-by: LLM trailer that v2 dropped by mistake. - Rebase on wireless/main (fefaac1176bf). - v2: https://lore.kernel.org/all/20260529143446.1374404-1-n05ec@lzu.edu.cn/ (local) - v1: https://lore.kernel.org/all/0e3f97ca5cfbeb67a8e60ca5c266f4335950816b.1779619788.git.xuyq21@lenovo.com/ (local) Review feedback from v2 and how it is addressed: Johannes wrote:
First of all, I think it's kind of overblown with the CC stable etc., can you actually find a situation where a driver reports such a thing?
We agree and have reworked the description. The only in-tree trigger we can demonstrate is mac80211_hwsim with a userspace medium: the medium requires CAP_NET_ADMIN in a user and network namespace and can then return forged TX status for the radio it serves. We are not aware of any in-tree driver or firmware reporting NSS 0 or out-of-range MCS values, so v3 no longer asks for a stable backport. Driver-side work is validating the same kind of metadata before it reaches mac80211 (e.g. the proposed "[PATCH wireless v2] wifi: mt76: mt76x02: validate TX-status rate index before mac80211 handoff", 2026-08-26), which is why v3 treats this as metadata hardening.
Secondly, I don't think it's the right place to be checking, we use the data a lot for other things in status handling, and might expand that, so it seems that instead of having specific checks for minstrel, we should have most of the checks in general (e.g. nss==0 is generally invalid), and only have the things that matter for minstrel specifically (say bandwidth) there [...]
That is what v3 does. ieee80211_tx_status_ext() and ieee80211_tx_rate_update() now sanitize both the legacy ieee80211_tx_rate array and the rate_info based entries before any consumer runs. minstrel_ht only keeps the checks that depend on its own tables.
But I also think that if this stuff really comes from firmware rather than being built by the driver, it should be the driver's responsibility to not report nonsense. I doubt we can protect against any driver nonsense here in mac80211.
Agreed - the sanitizing does not absolve drivers. It only makes sure that a bad status report cannot corrupt mac80211 state. We do not add a WARN_ON() for the invalid values because with panic_on_warn that would turn a driver bug into a denial of service.
Why drop it now, when before you were saying it was?
The Assisted-by: LLM tag was dropped by mistake while reworking the From/Signed-off-by addresses for v2. It is restored in v3. ---- details below ---- Bug details: minstrel_ht_tx_status() accepts both the legacy ieee80211_tx_rate array and rate_info based entries and turns the reported HT/VHT rate into a minstrel group and rate index. The validation helpers only checked that an entry was present and had tries recorded; they did not check that the reported NSS, bandwidth and MCS values are representable by the minstrel_ht rate tables. A VHT entry with idx = 0x7f (NSS 8, MCS 15) produced rates[15] in a table with MCS_GROUP_RATES (10) entries and an out-of-bounds access to struct minstrel_rate_stats. The patch: - drops invalid HT/VHT entries at the mac80211 status entry points; - rejects rates that do not map into minstrel_ht's tables in the rate control algorithm itself. Reproducer: A self-contained program enters a user and network namespace, creates a mac80211_hwsim radio, registers as its userspace medium, configures an AP with an associated station, injects a radiotap VHT frame on a monitor interface and returns the first VHT TX status with idx = 0x7f. It is unchanged from the initial submission (the full source was included with v1, see the link above) and is run in a KVM guest with CONFIG_UBSAN_BOUNDS. ------BEGIN crash log------ self-contained userns setup complete; injecting radiotap VHT traffic data TX sample: idx=0 count=1 flags=0x100 addr1=02:11:22:33:44:55 forging malformed VHT TX status: idx=0x7f flags=0x100 event=1 [ 1.026837] ------------[ cut here ]------------ [ 1.026841] UBSAN: array-index-out-of-bounds in net/mac80211/rc80211_minstrel_ht.c:409:33 [ 1.026845] index 15 is out of range for type 'minstrel_rate_stats [10]' [ 1.026848] CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 7.3.0-rc2-00458-gfefaac1176bf #1 PREEMPT(lazy) [ 1.026852] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-10.fc44 06/10/2025 [ 1.026853] Call Trace: [ 1.026869] <TASK> [ 1.026870] dump_stack_lvl+0x4d/0x70 [ 1.026879] ubsan_epilogue+0x5/0x2b [ 1.026882] __ubsan_handle_out_of_bounds.cold+0x4e/0x58 [ 1.026885] minstrel_ht_tx_status+0x98c/0xd70 [ 1.026892] ? srso_alias_return_thunk+0x5/0xfbef5 [ 1.026894] ? select_task_rq_fair+0x24d/0x1c20 [ 1.026898] rate_control_tx_status+0xac/0x130 [ 1.026901] ? ttwu_queue_wakelist+0x12d/0x260 [ 1.026905] ieee80211_tx_status_ext+0x2d5/0xc50 [ 1.026908] ? srso_alias_return_thunk+0x5/0xfbef5 [ 1.026910] ? sta_info_hash_lookup+0x95/0xd0 [ 1.026913] ieee80211_tx_status_skb+0x8a/0xc0 [ 1.026916] ieee80211_handle_queued_frames+0xb0/0xe0 [ 1.026921] ? __pfx_ieee80211_tasklet_handler+0x10/0x10 [ 1.026923] tasklet_action_common+0x159/0x260 [ 1.026928] ? tasklet_action+0xb/0x30 [ 1.026929] handle_softirqs+0xc6/0x300 [ 1.026932] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 1.026934] run_ksoftirqd+0x20/0x30 [ 1.026936] smpboot_thread_fn+0xf1/0x220 [ 1.026938] kthread+0xe1/0x120 [ 1.026941] ? __pfx_kthread+0x10/0x10 [ 1.026943] ret_from_fork+0x196/0x260 [ 1.026946] ? __pfx_kthread+0x10/0x10 [ 1.026947] ? __pfx_kthread+0x10/0x10 [ 1.026949] ret_from_fork_asm+0x1a/0x30 [ 1.026952] </TASK> [ 1.026962] ---[ end trace ]--- [ 1.026963] Kernel panic - not syncing: UBSAN: panic_on_warn set ... [ 1.064263] CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 7.3.0-rc2-00458-gfefaac1176bf #1 PREEMPT(lazy) [ 1.066479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-10.fc44 06/10/2025 [ 1.068420] Call Trace: [ 1.068978] <TASK> [ 1.069454] dump_stack_lvl+0x4d/0x70 [ 1.070288] vpanic+0x253/0x470 [ 1.071011] panic+0x66/0x70 [ 1.071694] check_panic_on_warn.cold+0xf/0x1e [ 1.072723] __ubsan_handle_out_of_bounds.cold+0x4e/0x58 [ 1.073906] minstrel_ht_tx_status+0x98c/0xd70 [ 1.074910] ? srso_alias_return_thunk+0x5/0xfbef5 [ 1.075992] ? select_task_rq_fair+0x24d/0x1c20 [ 1.077006] rate_control_tx_status+0xac/0x130 [ 1.078002] ? ttwu_queue_wakelist+0x12d/0x260 [ 1.078997] ieee80211_tx_status_ext+0x2d5/0xc50 [ 1.080033] ? srso_alias_return_thunk+0x5/0xfbef5 [ 1.081097] ? sta_info_hash_lookup+0x95/0xd0 [ 1.082074] ieee80211_tx_status_skb+0x8a/0xc0 [ 1.083068] ieee80211_handle_queued_frames+0xb0/0xe0 [ 1.084187] ? __pfx_ieee80211_tasklet_handler+0x10/0x10 [ 1.085356] tasklet_action_common+0x159/0x260 [ 1.086348] ? tasklet_action+0xb/0x30 [ 1.087182] handle_softirqs+0xc6/0x300 [ 1.088053] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 1.089129] run_ksoftirqd+0x20/0x30 [ 1.089930] smpboot_thread_fn+0xf1/0x220 [ 1.090835] kthread+0xe1/0x120 [ 1.091547] ? __pfx_kthread+0x10/0x10 [ 1.092393] ret_from_fork+0x196/0x260 [ 1.093242] ? __pfx_kthread+0x10/0x10 [ 1.094090] ? __pfx_kthread+0x10/0x10 [ 1.094927] ret_from_fork_asm+0x1a/0x30 [ 1.095817] </TASK> [ 1.096458] Kernel Offset: 0x2e400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 1.099071] Rebooting in 1 seconds.. ------END crash log----- Best regards, Yuqi Xu Yuqi Xu (1): wifi: mac80211: validate TX status rate metadata net/mac80211/rc80211_minstrel_ht.c | 59 ++++++++++++++++++++++--- net/mac80211/status.c | 69 ++++++++++++++++++++++++++++++ 2 files changed, 122 insertions(+), 6 deletions(-) base-commit: fefaac1176bf3cf002a8dc83339d6ed6a369941a -- 2.55.0